Пять проблем в процессах эксплуатации и поддержки Highload ИТ систем

Привет, Хабр! Десять лет я поддерживаю Highload ИТ системы. Не буду писать в этой статье о проблемах настройки nginx для работы в режиме 1000+ RPS или другие технические вещи. Поделюсь наблюдениями о проблемах в процессах, которые возникают в поддержке и эксплуатации таких систем.

Мониторинг

Техподдержка не ждет пока прилетит заявка с содержанием « Какого Почему… сайт опять не работает?». Поддержка через минуту после падения сайта уже должна увидеть проблему и начать её решать. Но сайт — вершина айсберга. Его доступность ставят на мониторинг одним из первых.

Как быть с ситуацией, когда остатки товаров интернет-магазина перестали приходить из ERP системы? Или CRM система, которая рассчитывает скидки для клиентов перестала отвечать? Сайт-то при этом с виду работает. Условный Zabbix получает свой 200 ответ. Дежурная смена не получила никаких уведомлений от мониторинга и радостно досматривает первую серию нового сезона «Игры престолов».

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

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

Взаимодействие с внешними системами

Любой сайт или мобильное приложение с годовым оборотом более миллиарда рублей взаимодействует с внешними системами. Начиная от вышеупомянутых CRM и ERP и заканчивая передачей данных о продажах внешней Big Data системе анализа покупок и предложения клиенту товара, который он точно купит ( на самом деле нет ). У каждой такой системы есть своя поддержка. И часто общение с этими системами вызывает боль. Особенно когда проблема глобальная и нужно анализировать её в разных системах.

Какие-то системы дают телефон или telegram своих админов. Где-то нужно писать письма менеджерам или ходить в баг трекеры этих внешних систем. Даже в разрезе одной большой компании разные системы часто работают в разных системах учёта заявок. Отследить статус заявки порой становится невозможно. Ты получаешь заявку в одной условной Jira. Затем в комментарии этой первой Jira ставишь ссылку на задачу в другой Jira. Во второй Jira в заявке кто-то уже пишет комментарий, что нужно позвонить условному админу Андрею, чтобы решить вопрос. И так далее.

Оптимальный вариантом решения такой проблемы было бы создание единого пространства для общения, например в Slack. Приглашение в него всех участников процесса эксплуатации внешних систем. А так же единого трекера, чтобы не дублировать заявки. Заявки должны отслеживаться в одном месте, начиная от оповещения мониторинга до вывода решения багов в прод. Вы скажете, что это нереально и у вас так исторически сложилось, что мы работаем в одном трекере, а они в другом. Появлялись разные системы, у них были свои автономные ИТ команды. Согласен и поэтому проблему нужно решать сверху на уровне CIO или product owner.

Каждая система, с которой вы взаимодействуете должна оказывать поддержку как услугу с четким SLA на решение проблем по приоритетам. А не тогда когда у условного админа Андрея найдется для вас минуточка.

Человек- бутылочное горлышко

У каждого на проекте ( или продукте ) есть такой человек, уход в отпуск которого вызывает у начальства судороги? Это может быть devops инженер, аналитик или разработчик. Ведь только devops инженер знает, на каких серверах установлены какие контейнеры, как перезагрузить контейнер в случае проблемы да и вообще любая сложная проблема без него не решается. Аналитик — единственный знает как работает ваш сложный механизм. Какие потоки данных куда идут. При каких параметрах запросов в какие сервисы, какие мы будем получать ответы.
Кто быстро поймет почему в логах ошибки и оперативно пофиксит критичный баг в проде? Конечно тот самый разработчик. Есть и другие, но почему-то только он понимает как устроены разные модули системы.

Корнем этой проблемы является отсутствие документации. Ведь если бы все сервисы вашей системы были бы описаны, то можно было бы разобраться с проблемой и без аналитика. Если бы devops выделил из своего плотного графика пару дней и описал бы все сервера, службы и инструкции по решению типовых проблем, то проблему в его отсутствии можно было бы решить и без него. Не нужно в отпуске быстро допивать своё пиво на пляже и искать wi-fi для решения проблемы.

Компетенция и ответственность сотрудников поддержки

На крупных проектах компании не скупятся на зарплату разработчикам. Хантят дорогих мидлов или сеньёров с аналогичных проектов. С поддержкой ситуация немного иная. Эти расходы всячески пытаются сократить. Компании нанимают недорогих вчерашних эникейщиков и смело идут в бой. Такая стратегия возможна, если речь идет сайте-визитке какого-нибудь завода в Зеленограде.

Если речь идёт о крупном интернет-магазине, то каждый час простоя стоит больше чем месячная зарплата админа-эникейщика. Возьмем за отправную точку 1 миллиард рублей годового оборота. Это минимальный оборот любого интернет-магазина из рейтинга ТОП-100 за 2018 год. Разделим эту сумму на количество часов в году и получим более 100 000 рублей чистых потерь. А если не считать ночные часы, то можно смело увеличивать сумму в два раза.

Но деньги ведь не главное, да? (нет, конечно главное) Есть еще репутационные потери. Час падения известного интернет-магазина может вызвать как волну отзывов в социальных сетях, так и публикации в тематических СМИ. А разговоры друзей на кухне в стиле «Не покупай там ничего, у них сайт постоянно не работает» вообще не поддаются измерениям.

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

Ответственность — навык который трудно развить. Он или есть у человека или нет. Поэтому на собеседованиях я стараюсь выявить её наличие разными вопросами, которые косвенно показывают привык ли человек брать ответственность на себя. Если человек отвечает, что выбрал ВУЗ, потому что так сказали родители или меняет работу из-за того, что жена сказала, что он мало получает, то с такими людьми лучше не связываться.

Взаимодействие с командой разработки

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

Разработчики постоянно перегружены. Они занимаются созданием новых фич. Фиксить баги с прода занятие скажем не самое интересное. Горят сроки для завершения очередного спринта. А тут приходят неприятные люди из поддержки и говорят: «Срочно бросай всё, у нас проблемы». Приоритет таких задач минимальный. Особенно когда проблема не самая критичная и основной функционал сайта работает, и когда релиз-менеджер не бегает с выпученными глазами и не пишет: «Срочно внести эту задачу в ближайший релиз или хотфикс».

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

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

Вопросы взаимодействия разработки и поддержки решает DevOps. Эту аббревиатуру часто употребляют в виде конкретного человека, который помогает создавать тестовые окружения для разработки, выстраивает CICD пайплайны и быстро выводит протестированный код в продакшн. DevOps — подход к разработке ПО, когда все участники процесса плотно взаимодействуют друг с другом и помогают быстрее создавать и обновлять программные продукты и услуги. Я имею в виду аналитиков, разработчиков, тестировщиков и поддержку.

Поддержка и разработка в таком подходе не разные отделы со своими целями и задачами. Разработка вовлечена в эксплуатацию и наоборот. Знаменитая фраза распределенных коллективов: «Проблема не на моей стороне» уже не так часто мелькает в чатах, и конечные пользователи становятся капельку счастливее.

Источник: habr.com