Главная » Хабрахабр » Кремниевая резня бензопилой

Кремниевая резня бензопилой

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

Помните Васю, которому всегда приходилось фиксить баги бухому в три часа ночи? Заглядывайте под кат, там Барух Садогурский (@jbaruch) и Леонид Игольник (@ligolnik) расскажут хоррор-историю про одного неудачливого дежурного. Это только начало.

Материал подготовлен на основе выступления Баруха и Леонида на осенней конференции DevOops 2017.

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

Тот рассказывает, что в понедельник он должен будет показать генеральному директору очень важную demo, но что-то не работает. Пока он ни о чем не подозревает, его коллега из техподдержки принимает звонок от клиента. Support сделал все, что мог (предложил выключить и включить), и эскалирует эту проблему дежурному. Нужно срочно устранить проблему.

Инженер техподдержки его будит и пытается объяснить проблему очень простыми словами: «Вот там что-то не работает, что-то не так». Вася дежурит один на весь проект, заниматься этим придется ему.

Вася выслушивает коллегу, обдумывает произошедшее и принимает единственно правильное решение…

Клиент с таким положением дел не согласен и эскалирует проблему саппорт-менеджеру. Инженер поддержки обижается, но все равно просит клиента подождать до понедельника. Вася — человек ответственный. Теперь уже тот звонит Васе и говорит, что это несерьезно: «Все-таки дело важное, клиент переживает, надо». Надо значит надо: кофе и потанцуем (поищем что-то в логах).

Сначала Вася 15 минут искал человека с доступом к правильному логу. В логах все оказалось совсем не просто. Но как? Его он нашел и получил лог. Вася ответственный, молодой и читает лог в ворде: совсем ничего не понятно. На почту в формате .doc, конечно же. Вася зависает на интересных вещах минут на 20, узнает много всего интересного, но ничего нужного в данный момент. Но есть ключевые слова, по которым можно поискать в Knowledge Base.

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

Спустя два-три часа работы они нашли hot-fix. Коллега — хороший товарищ, с горем пополам они понимают, в чем проблема, и начинают ее решать. Но как? Его надо сразу отдавать в продакшн. Но такой вариант не подходит, нужно же срочно. Есть change control board, который собирается по понедельникам раз в две недели.

Значит единственный вариант — послать jar-файл с двумя классами и абзацем объяснений по e-mail. Естественно, деплоить в продакшн нельзя, нет root. И вот, в 6-7 часов утра, наконец-то можно идти спать с чувством выполненного долга. Те ребята зайдут по ssh на продакшн и там этот jar-файл в WebSphere подложат в правильную директорию.

На 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 definition построен правильно и клиент понимает, что такое SLA, такого обычно не происходит. Severity начинает использоваться как инструмент манипуляции. Это взаимный процесс обучения, когда клиенты начинают понимать, что действительно очень важно, а что просто важно.

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

Это, опять же, зависит от контекста. SLA — гарантия ответа и решения в течение суток, но может быть быстрее.

Организационные проблемы

Вася не понял проблему до конца. Конечно, он же только что проснулся, а коллега из техподдержки еще и плохо объяснил. Лечится это только одним способом: билет. Билет (ticket) — это референс-номер, который рассказывает, о чем вообще речь. Это нужно для Васи, потому что вместо телефона саппорт мог сказать Васе «Открой нашу систему ведения тикетов и посмотри тикет номер 42». Это нужно по нескольким причинам. Во-первых, Вася, вместо того чтобы в сонном состоянии слушать коллегу, проснется, пойдет почитает тикет и поймет, насколько это важно. Во-вторых, проблема может быть и не одна.

Откуда саппорт знает, что именно Вася сегодня дежурит? Есть еще одно затруднение, которое влияет на общую картину: Васю нужно найти. Важно, чтобы было просто найти нужного человека. А вдруг он и Васю то не знает. Ну или другие, более навороченные системы. Решение — Virtual Extension с разными префиксами для инженера, продакшена и тд. С таким решением не надо гадать, куда звонить среди ночи, все переключается автоматически.

Title чата — номер того самого тикета. Еще удобнее — Escalation Chat в Slack, Telegram, Skype, где угодно. Одна из самых полезных фич такого чатика заключается в том, что не нужно ничего рассказывать тем, кто присоединяется к работе через какое-то время. Все общение по этому тикету между нужными людьми идет в этом чатике. О том, какие решения уже приняты, можно просто прочитать.

Кстати, в современных системах типа Zoom или Bluejeans весь нужный функционал уже встроен. Ну и virtual phone bridge, который можно сравнить с местом сбора при пожаре: все знают, куда идти в случае возникновения проблем.

Путь эскалации

Вася побоялся звонить сеньору, ведь они страшные. Что делать с этим? Поговорим про escalation path. Надо всегда знать, кого и когда будить или отрывать от работы. Это должно быть совершенно четко понятно всем: и тому, кто будит, и тому, кого будят. Еще нужно знать, куда звонить, если первый путь не сработал. Хороший escalation path идет вплоть до генерального директора компании.

Он должен быть в курсе критических проблем. Есть коммуникации, которые должны исходить от CEO.

Менеджер на побегушках

Следующая интересная позиция — manager on call. Он не обязательно должен быть технарем и принимать участие в решении проблемы. Во-первых, Вася среди ночи не может рассказать клиенту ничего полезного. Дежурный менеджер может помочь в такой ситуации. Кроме того, он может заняться координацией, управлением проектом в сложной ситуации, управлением ресурсами. Ведь работа должна идти бесперебойно.

Доступ к продакшену

Стоит ли давать Васе доступ к продакшену? Ведь не все — блестящие инженеры, и есть определенные вещи, на которых учиться не хотелось бы, клиенты обидятся. Это решается с помощью процесса деплоймента. Если процесс настроен правильно, то Вася может нажать кнопочку, которая в итоге его код на продакшн задеплоит. Если у вас есть нормальный continuous delivery pipeline, скорее всего, это можно делать автоматически (пройдут все тесты). Если нет, во многих компаниях решение принимает senior-инженер или менеджер. Он делает ревью, оценивает риск кода и принимает решение.

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

Смена дежурных

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

Другие проблемы

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

Как это воплотить?

Но как же это все привести в компанию? Нужно понимать, что это займет какое-то время.

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

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

Выводы

Переходим к главному. Несмотря на то, что мы, технари, влюблены в tech, самое главное — это не продукты и технологии, которые используются в компании, а чувство дежурного «Я вовлечен в процесс улучшения продукта» (ну или самого дежурства). Многие понимают, что надо дежурить, но хочется видеть улучшения. Люди должны осознавать, что благодаря им и их улучшениям все становится лучше.

P.S

Хотим порекомендовать книжку под названием Drive. Это — книга о мотивации людей, которые работают в профессиях типа нашей. Эта мотивация состоит из трех основных составляющих и (спойлер) ни одна из них — не деньги.

Приходите, будет много интересного: вот доклады, вот Джон Уиллис, а вот вечеринка с BoF-ами и караоке. Уже в это воскресенье Барух и Леонид выступят с докладом «#DataDrivenDevOps» на DevOops 2018 в Петербурге. Ждем вас!


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Кардиофлешка ECG Dongle: что нового

Прошло два года с тех пор, как мы показали прототип гаджета, полностью собираемого в РФ. На тот момент производитель пообещал выполнить несколько конкретных действий по улучшению продукта, и, в общем-то, можно сказать, что пришло время посмотреть, что же изменилось. ЭКГ-донгл ...

Может ли искусственный интеллект оставить букмекеров без работы?

«Победа искусственного интеллекта над футбольными экспертами» – таким мог стать заголовок этой статьи про результаты футбольного соревнования. Мог бы, но, увы, не стал. Я слишком поверхностно разбираюсь в футболе, чтобы на что-то претендовать, но желание принять участие в конкурсе все-таки ...