Кремниевая резня бензопилой
Дежурство — это важная составляющая большинства современных организаций. Ведь часто бывает, что проблема прилетает и в 3 часа ночи. Но кто должен дежурить? И как организовать этот процесс так, чтобы он имел смысл?
Заглядывайте под кат, там Барух Садогурский (@jbaruch) и Леонид Игольник (@ligolnik) расскажут хоррор-историю про одного неудачливого дежурного. Помните Васю, которому всегда приходилось фиксить баги бухому в три часа ночи? Это только начало.
Материал подготовлен на основе выступления Баруха и Леонида на осенней конференции DevOops 2017.
Итак, дежурство. В качестве примера возьмем гипотетического Васю, который работает в некой компании не так давно, около года. Сегодня пятница и так получилось, что дежурит именно Вася. Все проходит хорошо: Вася спит, и сны его прекрасны.
Пока он ни о чем не подозревает, его коллега из техподдержки принимает звонок от клиента. Тот рассказывает, что в понедельник он должен будет показать генеральному директору очень важную demo, но что-то не работает. Нужно срочно устранить проблему. Support сделал все, что мог (предложил выключить и включить), и эскалирует эту проблему дежурному.
Вася дежурит один на весь проект, заниматься этим придется ему. Инженер техподдержки его будит и пытается объяснить проблему очень простыми словами: «Вот там что-то не работает, что-то не так».
Вася выслушивает коллегу, обдумывает произошедшее и принимает единственно правильное решение…
Инженер поддержки обижается, но все равно просит клиента подождать до понедельника. Клиент с таким положением дел не согласен и эскалирует проблему саппорт-менеджеру. Теперь уже тот звонит Васе и говорит, что это несерьезно: «Все-таки дело важное, клиент переживает, надо». Вася — человек ответственный. Надо значит надо: кофе и потанцуем (поищем что-то в логах).
В логах все оказалось совсем не просто. Сначала Вася 15 минут искал человека с доступом к правильному логу. Его он нашел и получил лог. Но как? На почту в формате .doc, конечно же. Вася ответственный, молодой и читает лог в ворде: совсем ничего не понятно. Но есть ключевые слова, по которым можно поискать в Knowledge Base. Вася зависает на интересных вещах минут на 20, узнает много всего интересного, но ничего нужного в данный момент.
Что Вася делает дальше? Нужно кого-то искать, но Вася — инженер молодой и будить Senior-а страшно. Поэтому он решает, что нужно позвонить коллеге, такому же джуниору.
Коллега — хороший товарищ, с горем пополам они понимают, в чем проблема, и начинают ее решать. Спустя два-три часа работы они нашли hot-fix. Его надо сразу отдавать в продакшн. Но как? Есть change control board, который собирается по понедельникам раз в две недели. Но такой вариант не подходит, нужно же срочно.
Естественно, деплоить в продакшн нельзя, нет root. Значит единственный вариант — послать jar-файл с двумя классами и абзацем объяснений по e-mail. Те ребята зайдут по ssh на продакшн и там этот jar-файл в WebSphere подложат в правильную директорию. И вот, в 6–7 часов утра, наконец-то можно идти спать с чувством выполненного долга.
В понедельник Вася приходит на работу и видит необычную картину. На VP of Engineering наорал гендиректор, потому что на гендиректора наорал клиент, потому что на него наорал его гендиректор. Оказывается, что решить проблему не получилось.
У начальства есть четыре вопроса: «Что случилось в пятницу?»; «Почему я об этом узнал от босса в понедельник?»; «Почему фикс занял шесть часов?» и «Кто виноват?». В комнату вызываются опсы, которые говорят, что это не их проблема. В комнату вызывается Вася и прочий дев, который тоже говорит «Ничего не работало». Вся эта игра в картошку продолжается до обеда.
Поскольку время обедать, принимается решение «Окей, оно само сломалось, никто не виноват». Конец истории.
Устроим небольшой разбор полетов: давайте пройдемся по этому кошмару и попробуем дать ответы на все вопросы.
Кто должен дежурить
Дежурить могут сисадмины (или более модное слово — SRE). Они этим занимаются не первый год, у них все хорошо поставлено. Может дежурить DBA, могут те, кто занимается месседжингом. Если повезло, дежурит NOC (network operation center) — это когда всех этих ребят сажают в одну комнату. У них есть runbooks, в которых написано, что делать в сложной ситуации.
С этими ребятами все понятно, они профи в дежурстве. Но, к сожалению, в DevOps есть вторая часть уравнения, которая не очень желает дежурить. Как заставить вторую часть? Да и надо ли заставлять, ведь профи должны осознавать важность дежурства.
Есть две причины, почему люди не хотят дежурить. Одна — это когда так:
Никто не захочет дежурить, когда все плохо. Решение у этой проблемы довольно простое:
Нужно писать хороший код, все просто. Но этому тоже нужно научиться. Возникает новый вопрос: «Как научиться?». Нужно засунуть пальцы в розетку — #painisinstructional. Боль помогает.
Дежурства сами по себе улучшают качество кода. Тот же Вася в понедельник, скорее всего, исправит свои ошибки, чтобы не сидеть еще одну ночь в поиске ошибок.
Барьеры при дежурстве
При дежурстве встречаются некоторые барьеры, которых там быть не должно. Пройдемся по Васиному пятничному фиаско. Помните, как он читал логи в ворд-документе?
Все мы любим продукты Microsoft, но в современном мире так работать нельзя. Есть очевидные вещи про логи, которые должен понимать каждый. Главный пункт — это количество тулов, которые решают эти проблемы: Logstash, Loggly, Sumo logic, Kibana. Их нужно использовать.
Возвращаясь к вопросу доступа: почему не дают доступ к логу? Ответ — sensitive data. Клиентам пообещали защищать данные от утечек. Значит, логи никому нельзя показывать или нужно пользоваться системами с функционалом data masking. Он сам скрывает персональные данные и не показывает их человеку без нужного уровня доступа. Все сегодняшние инструменты для парсинга логов имеют эту функциональность.
Еще одно преимущество этих инструментов — на них можно построить «мониторинг для бедных». Например, в логах, увидев определенное кол-во ошибок (переполнена очередь и т.п.), можно триггернуть аллерт.
Кто определяет важность проблемы
Как понять, ложиться дежурному спать или срочно бежать исправлять проблему? Кто назначает severity? Кто решает, насколько критична проблема? Решает support. А почему? Потому что саппорт имеет видение проблемы. Он знает, насколько все плохо.
Более того, сегодня почти все компании работают по принципу «Continuous Delivery», поэтому все клиенты получают все фичи одновременно (и заодно баги). Допустим, есть баг, который для клиента выглядит как «Что-то там не работает, ничего страшного». В этот же момент саппорт видит сотни оповещений о проблеме, и это, очевидно, серьезно.
Еще в определении важности проблемы участвует клиент. Но есть проблема — клиент не всегда верит, что его небольшую проблему починят и ставит наивысшую важность. Severity начинает использоваться как инструмент манипуляции. Но если severity definition построен правильно и клиент понимает, что такое SLA, такого обычно не происходит. Это взаимный процесс обучения, когда клиенты начинают понимать, что действительно очень важно, а что просто важно.
Клиентам нужно давать возможность выставлять важность, потому что компании-производителю продукта не всегда понятен контекст проблемы.
SLA — гарантия ответа и решения в течение суток, но может быть быстрее. Это, опять же, зависит от контекста.
Организационные проблемы
Вася не понял проблему до конца. Конечно, он же только что проснулся, а коллега из техподдержки еще и плохо объяснил. Лечится это только одним способом: билет. Билет (ticket) — это референс-номер, который рассказывает, о чем вообще речь. Это нужно для Васи, потому что вместо телефона саппорт мог сказать Васе «Открой нашу систему ведения тикетов и посмотри тикет номер 42». Это нужно по нескольким причинам. Во-первых, Вася, вместо того чтобы в сонном состоянии слушать коллегу, проснется, пойдет почитает тикет и поймет, насколько это важно. Во-вторых, проблема может быть и не одна.
Есть еще одно затруднение, которое влияет на общую картину: Васю нужно найти. Откуда саппорт знает, что именно Вася сегодня дежурит? А вдруг он и Васю то не знает. Важно, чтобы было просто найти нужного человека. Решение — Virtual Extension с разными префиксами для инженера, продакшена и тд. Ну или другие, более навороченные системы. С таким решением не надо гадать, куда звонить среди ночи, все переключается автоматически.
Еще удобнее — Escalation Chat в Slack, Telegram, Skype, где угодно. Title чата — номер того самого тикета. Все общение по этому тикету между нужными людьми идет в этом чатике. Одна из самых полезных фич такого чатика заключается в том, что не нужно ничего рассказывать тем, кто присоединяется к работе через какое-то время. О том, какие решения уже приняты, можно просто прочитать.
Ну и virtual phone bridge, который можно сравнить с местом сбора при пожаре: все знают, куда идти в случае возникновения проблем. Кстати, в современных системах типа Zoom или Bluejeans весь нужный функционал уже встроен.
Путь эскалации
Вася побоялся звонить сеньору, ведь они страшные. Что делать с этим? Поговорим про escalation path. Надо всегда знать, кого и когда будить или отрывать от работы. Это должно быть совершенно четко понятно всем: и тому, кто будит, и тому, кого будят. Еще нужно знать, куда звонить, если первый путь не сработал. Хороший escalation path идет вплоть до генерального директора компании.
Есть коммуникации, которые должны исходить от CEO. Он должен быть в курсе критических проблем.
Менеджер на побегушках
Следующая интересная позиция — manager on call. Он не обязательно должен быть технарем и принимать участие в решении проблемы. Во-первых, Вася среди ночи не может рассказать клиенту ничего полезного. Дежурный менеджер может помочь в такой ситуации. Кроме того, он может заняться координацией, управлением проектом в сложной ситуации, управлением ресурсами. Ведь работа должна идти бесперебойно.
Доступ к продакшену
Стоит ли давать Васе доступ к продакшену? Ведь не все — блестящие инженеры, и есть определенные вещи, на которых учиться не хотелось бы, клиенты обидятся. Это решается с помощью процесса деплоймента. Если процесс настроен правильно, то Вася может нажать кнопочку, которая в итоге его код на продакшн задеплоит. Если у вас есть нормальный continuous delivery pipeline, скорее всего, это можно делать автоматически (пройдут все тесты). Если нет, во многих компаниях решение принимает senior-инженер или менеджер. Он делает ревью, оценивает риск кода и принимает решение.
И еще до того, как появился хотфикс, должны быть задействованы задокументированные инструменты для траблшутинга. Одна из самых частых проблем дежурного: он начинает думать, как включить дебаг или поменять уровень логов. При этом со всем остальным проблем нет. Желательно иметь задокументированные пути решения проблем.
Смена дежурных
Теперь поговорим о процессе дежурства, который обычно занимает неделю. В какой-то момент надо меняться. Чтобы меняться эффективно, это надо делать в определенное время. Нужно планировать все четко и желательно уметь эффективно передать проблемы следующему дежурному. Во многих компаниях это делается стандартным митингом, или создается страница, в которой дежурный ведет небольшой журнал.
Другие проблемы
Есть еще разные другие проблемы, которые нужно решать. Одна из них — сертификация доступа к продакшену. Желательно провести элементарную сертификацию, чтобы человек показал, что он понимает, что можно, а что нельзя.
Как это воплотить?
Но как же это все привести в компанию? Нужно понимать, что это займет какое-то время.
Нужно начинать с сеньор-ребят на дежурстве. Они имеют опыт и знают, что и как чинить. У сеньора меньше проблем: есть доступ к логам и т.п.
Желательно начинать еще в маленькой команде. Если же команда уже большая, нужно создать маленькую внутри нее. Дальше, когда все начнет работать хорошо, можно и остальных пристыдить.
Выводы
Переходим к главному. Несмотря на то, что мы, технари, влюблены в tech, самое главное — это не продукты и технологии, которые используются в компании, а чувство дежурного «Я вовлечен в процесс улучшения продукта» (ну или самого дежурства). Многие понимают, что надо дежурить, но хочется видеть улучшения. Люди должны осознавать, что благодаря им и их улучшениям все становится лучше.
P.S
Хотим порекомендовать книжку под названием Drive. Это — книга о мотивации людей, которые работают в профессиях типа нашей. Эта мотивация состоит из трех основных составляющих и (спойлер) ни одна из них — не деньги.
Уже в это воскресенье Барух и Леонид выступят с докладом »#DataDrivenDevOps» на DevOops 2018 в Петербурге. Приходите, будет много интересного: вот доклады, вот Джон Уиллис, а вот вечеринка с BoF-ами и караоке. Ждем вас!
