Повышение качества разработок и онлайн контроль ошибок

Всем доброе время суток. Давно я уже ничего не писал на данном ресурсе, однако, надо бы исправить это дело.

О чем я хочу поговорить сегодня ? Если я скажу о том, что я хочу говорить про то, как интегрировать 1С с неким “100500” сервисом, то вряд ли кто-то отнесется к этому с той серьезностью, которую бы мне хотелось получить.

Поэтому я скажу по другому:

Я хочу поговорить про качество обслуживания баз 1С

Заинтриговал? Но поверьте, я не хочу говорить про то, что надо делать тестирование, отладку, писать сценарии и прочее прочее прочее. Все и так про это уже давно знают. А хотелось бы мне поговорить про те проблемы, которые уже случились, они есть, но никто о них не знает.

Позвольте задать вопрос — как часто вы пролистываете журнал регистраций на поиск ошибок?

Задел за живое? 🙂 Я столько раз слышал от разработчиков — какой этот журнал не удобный, что надо писать свои системы логирования и анализа, что надо делать то и это, а в итоге — никто ничего не делает.
Проще всего — мобильным разработчикам, так как у них нет журнала регистрации, и они не могут подключиться удаленно и посмотреть на эти все ошибки.

Почему я решился на написание именно этой статьи?

Честно? Мне надоело нытье моих собратьев о том, что клиенты жалуются, говорят что в программе много ошибок, что 50 раз в день они нарываются на какие-то баги, а по факту — это всего лишь 2-3 ошибки в день.
Что коллегам по цеху не удобно листать эти полотнища в виде ЖР и искать в них зерно истины. Что вот прям завтра, они поднимут свою систему для этих целей и вот тогда то…

И так, для кого эта статья предназначена?

1. Для администраторов баз данных клиента (как внутренних, так и внешних)
2. Для специалистов тех поддержки
3. Для разработчиков (наконец).

 

Теперь предлагаю пофантазировать и ответить на вопрос “А следили ли Вы бы за ошибками?”, если:

1. Была подписка на все ошибки
2. Можно было бы в онлайне отлавливать ошибки по всем клиентам, по всем базам данных, по 500 РИБам, по мобильным устройствам? И видеть это все в браузере/телефоне/телевизоре?
3. Если бы ошибки можно было группировать, смотреть когда они появились в первый раз, когда был последний раз, сколько пользователей с ними столкнулись, как часто это было?
4. Если бы сервис показывал в каких версиях расширения/конфигурации эта ошибка была ранее?
5. Если бы для реализации всего этого — не надо было бы платить ни копейки и иметь квоту в 170 000 запросов в день? (во всяком случае — пока)
6. Если бы вы могли взять любую базу клиента, прописать пару строк, потратить 10 минут времени на перекур и собрать анализ по всем ошибкам этого клиента, которые попали в журнал регистраций за последних 30 дней?
7. Если бы можно было дать доступ клиенту к спискам именно его ошибок, чтобы он сам отмечал те ошибки, которые являются критичными, и мог “затыкать” рот Марьи Ивановне, которая говорит, что у нее 100500 ошибок в день, а по факту всего 2-3?
8. Если бы на внедрение всего этого — надо было бы потратить всего 15 минут времени?
9. Если бы этот ресурс предоставлял гигант IT мира?
10. Если бы вы были клиентом, а не программистом, и вы хотели бы “втихаря” собирать реальную статистику ошибок в базе данных, для того, чтобы дать нагоняя IT отделу, или компании, которая обслуживает, и вам бы для этого не понадобилось владеть огромными навыками программирования?
11. … куча всяких других рекламных если…

Надеюсь, что ответ — “да”. И я уже не один…

Раскрываем карты

Сервис Google Cloud Platform

Размещается по адресу https://console.cloud.google.com

Там появился новый сервис, который позволяет отлавливать баги. Сейчас он находится в статусе беты, так что им можно пользоваться почти безвозмездно. Кроме этого — Google дает нам бесплатный бонус на 300$ на один год, который можно активировать уже после того, как сервис выйдет из беты. Пока Google дает 170 000 запросов в день бесплатно, про остальное — надо с ними списываться и решать, цен в открытом доступе пока нет.

Выглядит это все в итоге вот так:

По пунктам:

1. Выбор проекта, т.е. можно завести под каждого клиента отдельный проект
2. Сервисы, мы их используем в качестве имени конфигурации/расширения где произошла ошибка
3. Версии — версии конфигурации или расширения
4. Фильтр по типам задач
5. Автоматическое обновление страницы ошибок. Очень помогает, когда в офисе на стене висит телевизор и в нем появляются все ошибки за текущий день.
6. Можно включить уведомления, которые бы отправлялись в случае новых ошибок
7. Период анализа ошибок.

Посмотрим одну ошибку детальнее:

Тут есть — описание ошибки, где она возникла, в какой строке, в каком модуле.
Кроме этого — четко видно, сколько раз она проявлялась и сколько РАЗНЫХ пользователей было затронуто ею.
Так же видно, где она проявлялась, в каких расширениях/конфигурациях и их версиях.
Ну и когда она была зарегистрирована первый раз и последний.
Ну и вишенка на торте, для тех, кто уже перешел в гит — если нажать на ссылку ошибки, там где ее путь слева вверху, то появится вот такое окно:

Т.е. вы можете прямо сразу перейти в гит, и там увидеть контекст вызова.
Остальные плюшки тут интуитивно понятны, так что не буду на них заострять внимание.

Краткий план действий

Понравилось? Если да, то чтобы это все реализовать, нам необходимо проделать несколько шагов:

1. Зарегистрировать Google аккаунт (если еще есть те, у кого его нет)
2. Зайти в консоль Google Cloud Platform
3. Создать нужный проект
4. Включить использование API Stackdriver Error Reporting
5. Сгенерировать ключ для API
6. Накатить расширение на базу и прописать в модуле настроек ID проекта и ключ
7. Нажать кнопку — выгрузить данные ЖР
8. Выпить кофе
9. Посмотреть на результат в консоле

Если знать что и как делать — все шаги занимают 10 минут. Приступим.

Создание проекта для выгрузки

Я надеюсь, что обычный Google аккаунт есть уже у всех, так что идем сразу дальше.
Переходим по ссылке: https://console.cloud.google.com
Соглашаемся с условиями.
Идем в раздел регистрации ошибок:

Нас попросят создать проект:

Нажимаем на создание, и пишем имя проекта, оно нам надо будет далее. Я называю их как “ua-company-db”, т.е. страна, внутренне названии компании и имя базы, если я их разделяю.
Если все будет хорошо, то мы увидим вот такую картинку:

 

Теперь нам надо активировать API, для этого идем по этой ссылке: https://cloud.google.com/error-reporting/reference/
И нажимаем вот на эту кнопку:

Нас перекинет потом вот на эту страницу:

Где мы выбираем ранее созданный проект. И жмем Далее.
Теперь нас просят создать ключи, по которым мы будем подключаться к сервису:

Теперь нам надо создать ключ доступа через API, для этого идем в нужный раздел:

И создаем ключ для доступа к API:

Указываем имя ключа, а так же можем настроить ограничение использования, это надо, если разнесены сервер 1С центральный и тестовый, и чтобы случайно не послать с тестового сервера ошибки — можно указать конкретный адрес/подсеть, откуда будут приниматься уведомления. Плюс, это безопасность. Но мы никаких ограничений не ставим, во всяком случае для теста, ключ потом можно удалить и создать новый:

И жмем на кнопку Создать.
После этого — появится окошко с ключем:

Копируем его куда-то и закрываем окно.

В итоге у нас должно быть вот такое:

И последнее что нам надо — это ID проекта:

Все, теперь мы создали все, что нам было необходимо, идем обратно в дашборд ошибок:

Итого, все это мы проделывали для двух вещей:

• ID проекта, в нашем случае это test-1c-log
• Ключ доступа, в нашем случае это AIzaSyB3cq1-9TksRyzP_r00wYlwi1pL-d2G7x4

Тестирование

Для теста нам понадобится просто платформа 8.3.10 или новее. Создадим пустую базу, и подключим туда расширение.
Вообще — механизмы будут работать везде, но, платформа должна уметь формировать JSON, хотя, можно и собрать его руками, через СтрШаблон. Кроме этого — платформа должна будет уметь отправлять POST запросы, но опять таки, есть cURL, так что по большому счету — этот сервис можно интегрировать даже с 7.7. При желании. При достаточном желании.

Создаем пустую базы данных, и цепляем к ней расширение. Не забываем у расширения снять обе галочки, а то нас не выпустят во внешний мир.
Идем в модуль настроек в расширении, видим такую картину:

Сюда мы потом пропишем ключи доступа. НО! Пока ничего не пишем. Запускаем в режиме предприятия, открываем обработку GCP тест:

И жмите пару раз на кнопку Тест ошибки, в этот момент программа попробует отправить ошибку в сервис, но, так как мы не указали данные подключения, программа зафиксирует ошибки в журнал регистрации, а нам этого и надо для тестов.
Нажатие на эту кнопку вызывает вот эту функцию:

После того как ткнем кнопку пару раз, идем в журнал регистрации и проверяем там, что ошибки наши зафиксированы:

Теперь возвращаемся в конфигуратор, в модуль настроек, и заполняем данными:

Обновляем, запускаем режим предприятия, жмем кнопку теста еще один раз, и идем уже теперь на наш трекер ошибок, и почти сразу видим (иногда, для отображения первой ошибки нового проекта может пройти от минуты до 5, так что не ожидайте увидеть первую ошибку через секунду):

Видим количество ошибок = 1, теперь выбираем в обработке теста сегодняшнюю дату и жмем Выгрузить журнал регистрации. Ждем немного, и у нас появляются все эти ошибки.
Вот и все.

Итого

Если пропустить этап первого получения ключа, то тут все сводится к накатыванию расширения на базу, прописывание ключа и проекта в настройках и все.

Кейс. Обращается ко мне клиент, хочет чтобы его взяли на обслуживание. Я создаю новый проект, подключаю к базе расширение, или выношу весь функционал во внешнюю обработку, запускаю выгрузку ТЖ. Иду курить и пить кофе. Прихожу через 15 минут и показываю ему “весь ужас” его базы. Где количество ошибок может достигать сотен, а одни и те же ошибки — тысяч, а то и десятков.

Кстати, если вы посмотрите функцию НеОшибки, то она так раз и сделала чтобы отлавливать не ошибки конфигурации:

Если в комментарии есть встречающиеся строки из этого массива, то я их пропускаю как не ошибки. Также пропускаются ошибки, у которых нету комментария.

Где это реально используется? Мы используем это у клиентов где сотни РИБ узлов, для анализа ошибок.

Как мы это используем — в двух вариантах, есть проект, куда сливается именно журнал регистраций, а есть проект, куда сливаются предвиденные ошибки.
Так как в журнале регистрации не всегда есть возможность адекватно распарсить ошибку, а там где мы отлавливаем ошибки попытками — мы сливаем их в конкретный проект, и после этого — связываем с жирой.

P.S.

Не советую вот в таком виде запускать это на реальном крупном проекте, все таки это упрощенная модель. У нас реализовано все немного сложнее. Например, отправка ошибок идет через фоновые задания, чтобы не тормозить выполнение основного кода. Ошибки кешируются, если нет интернета. И т.д.

P.P.S. Сервис бесплатный, по крайней мере пока он находится в стадии теста, но даже если он станет платным, есть возможность активировать 300$ бонуса на один год, и таки год им пользоваться бесплатно, а дальше уже решать.
Ну и конечно, просмотреть текущий уровень квот можно в специальном разделе

И тут красиво показывается сколько запросов за текущий день было сделано.

Заключение

Надеюсь, что теперь качество ваших продуктов и скорость реакции возрастет в разы. Но, это всего лишь один из маленьких пунктов в технологиях, которые дает Google.

Кроме этого, мы используем еще и FireBase и Google Analitics, где мы строим карты пользования магазинами 1С, вычисляем каким функционалом пользуются часто, а какой надо удалить, какие есть бест практики, как быстро в среднем отрабатывает функционал, и многое многое другое.

Кстати, про Google Analitics будет доклад на майском хакатоне . https://isthisdesign.org/

Цель подобного подхода

На самом деле на ближайшем хакатоне (если кто не в курсе он пройдет в мае в Москве), будет второй день для разбора проблем https://isthisdesign.org/shedule#day2

Я предполагаю, что проблема “Мониторинг 1С” на ней возникнет, и если возникнет я поделюсь вот этими своими наработками и/или расскажу — как мы с этим работаем. Видь просто выгрузить куда то это одно, а уметь читать и использовать — это уже другое. Возможно это не похоже на пропагандируемый ЦУП и elasticSearch, но проблему ведь решает и результат отличный. Тем более, что для этого не надо иметь свою инфраструктуру и специализированные знания.