Ситауция: на сайте мониторинга есть список сенсоров и их состояний «ОК» или «Есть проблема». Какое должно быть состояние, если в код сенсора завершился с ошибкой? При этом, сенсор выполняется на наших серверах, а не клиентских.

Проблема: По правилам pl7, нам нужно выводить ошибки в коде на самый верх: Traceback выводится в тексте сенсора, сам сенсор переводится в состояние «Неисправен». Это хорошо, т.к. клиент увидит что проблема у нас и даст фидбек с описанием проблемы. Но проблема в том, что у клиента будет негатив.

Решение: Админом облачных сервисов является компания разработчик. Поэтому клиенту пишем «Временно недоступно», а ошибку поднимаем в максимально неизменном виде админу разработчика или в поддержку разработчика, с очень высоким статусом активности, с смс и вплоть до блокировки админу интернета пока не обработает. При отладке мы также будем видеть «Временно недоступно» и знать что есть проблема.

Ситуация: Сенсор в системе мониторинга может упасть из-за ошибки в коде самого сенсора. При этом, для пользователя сенсор отобразится как провальный, в тексте сенсора пользователь увидит traceback, возможно ему даже уйдет смс с оповещением о поломке сенсора. Например: баг в коде проверки доступности сайта - сенсор «красный», в информации traceback питона, в телефоне клиента смс: «Ваш сайт недоступен!»

Проблема: Это реализовано согласно правилам Pl7:

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

Выводить подробный стек ошибок до строчки кода прямо пользователю в расширенное окно ошибки.

Но, очевидно, что клиента подобный трейсбек на сайте не устроит, а если мы будем ловить фидбек от разбуженного нами ночью клиента - долго мы с этим клиентом не проживем.

Получается противочечие.

Порассуждаем: Важно замечать и исправлять баги, а клиент - наш самый главный контроллер в этом плане. Но дергать клиента - это дорого. При этом мы знаем, что:

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

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

Мы знаем, что ошибки будут всегда, даже в самом отлаженом коде. Значит мы будем платить постоянно.

Если подумать, можно понять смысл правила про ошибки в pl7: нужно, чтобы все ошибки были замечены, а все важные - еще и починены.

Можно убрать «остроту» проблемы, выключив оповещение по смс. Действительно, зачем будить ночью клиента из-за наших проблем? Только в этом случае возникает проблема как в статье http://opencarbon.ru/правила_разработки:как_не_надо_делать:2018-12-04_молчаливые_ошибки - пользователь не увидит проблему, если мы ему не сообщим! В итоге о проблеме мы тоже не узнаем.

Можно пофантазировать, что правило про вывода ошибок относится только к утилитам и программам/сервисам, которыми сейчас пользуется клиент. Другими словами, если мы запускаем программу на компьютере или открываем страницу сайта и мы не можем получить необходимый результат (результат программы, страницу на сайте) - мы должны показать ошибку и, по правилу, максимально подробную. А сенсорами (которые запускаются на наших серверах) пользователь не пользуется, он сам их не запускает, у сенсоров пользователь - это администраторы серверов где они работают и ошибку должен видеть администратор!

Как нужно: Соблюдать правила pl7 очень важно, но иногда нужно понимать что они имеют в виду.

• Важно, чтобы разработчики получали оповещения об ошибках и они исправлялись. Так как система мониторинга - это сервис, то пользователем приложения «сенсор» - являемся мы, как администраторы серверов. При этом, раз сервера администрируем мы - подключать клиента для исправления проблем совершенно не обязательно.

• «Красный» сенсор - это результат успешного выполнения сенсора, как и «зеленый сенсор». Т.е. программа сенсора корректно выполнила свой код и решила, что есть проблема - о чем сообщает в сервис мониторинга.

Но как донести ошибку до админа?

Для этого подходят системы тикетов (создавать тикеты при ошибках) или системы сбора ошибок, такие как sentry. Можно сделать сенсор, который анализирует логи демонов, на предмет ошибок. При этом, любая система должна быть интегрирована в бизнес-процессы разработки, все ошибки должны обрабатываться.

Настроить и отладить такую систему с нуля - задача не из быстрых, поэтому показывать ошибку пользователю - это действительно хорошее решение, но только на этапе MVP, когда клиенты обладают большой лояльностью к нам и будут сообщать нам о проблемах, помогать нам становиться лучше. В дальнейшем от такой схемы нужно уходить и это не противоречит правилам pl7 «Программа должна быть громкой и писать о проблемах на экран».

~~OWNERAPPROVE~~