Наш перевод статьи Things I Learned Managing Site Reliability for Some of the World’s Busiest Gambling Sites на русский язык. Благодарим Иана Миела за то, что поделился с миром своим замечательным опытом. Оригинал статьи: https://hackernoon.com/things-i-learned-managing-site-reliability-for-some-of-the-worlds-busiest-gambling-sites-742b80a2be0c. Перевел Vasiliy Alferov, twitter, Linkedin
tl;dr
Несколько лет я проработал в 3-й линии поддержки одного из самых высоконагруженных игровых сайтов в малоизвестной компании, которая создала и эксплуатировала ядро-бэкенд для разных бизнесов, каждый из которых приносил миллионы фунтов в час. Пару лет назад я ушёл оттуда, и теперь настало подходящее время для того, чтобы попытаться понять, чему меня это научило.
По многим причинам то, что мы делали там очень похоже на штуку, которую сейчас называют SRE [Site Reliability Engineering/Обеспечение Надежности Сайта — прим. перев.] (Я буду называть это SRE, хотя в то время такого термина еще не существовало). Мы дежурили, в наши обязанности входила реакция на инциденты, мы писали рекомендации для переделок в софте, давали надежную обратную связь командам разработчиков и взаимодействия с клиентами, управляли эскалациями, занимались авариями, обслуживали систему мониторинга и все в таком духе.
Когда я присоединился к команде там уже было 5 инженеров (все бывшие разработчики и тех.лиды), и когда я покинул команду это число увеличилось до 50 или около того людей с разным опытом в нескольких локациях.
Я хочу сейчас сконцентрировать внимание на процессах и документации, потому что считаю везде, где я об этом читал, слишком мало полезной информации
Если вы хотите узнать больше — есть крутой ресурс: Google SRE book.
Процессы
Процессы жизненно необходимы для правильной работы и масштабирования SRE. Это основа всех достижений. Когда я пришёл в команду, в ней было много плохих практик, тикет система была, но в ней было полно односторочных закрытий: “Сайт лежит. Починил, закрываю”
Команда SRE, в общем-то, это фабрика по переработке информации и должна действовать соответственно. Как фабрика не может работать не отладив перемещение комплектующих, и точно также SRE команда не должна игнорировать движение информации и знаний.
Самое частое возражение, которое я слышу о внедрении четких процессов, то что это “убивает творчество”. На самом деле эффективная организация процессов освобождает мозг от деталей и позволяет более творчески мыслить (а плохо построенные процессы могут все еще больше запутать).
На эту тему есть отличная книга ‘The Checklist Manifesto’, она нас на многие изменения вдохновила, почти все ребята в команде ее прочли. Там приводятся примеры подходов из авиации, которые позволяют невероятно творчески подходить к решениям в условиях стресса, при помощи зазубривания до автоматизма рутинных действий. Об одном таком случае даже снято кино, в котором пилот говорит о чеклистах и вызубренных процедурах открывающих быстрое креативное мышление и контроль в стрессовой ситуации. В общем-то мы использовали то же самое: в ситуациях, требующих быстрого реагирования опытный инженер закапывается в поиск решения, а его более молодой коллега прогоняет чеклист.
Еще одна распространенная критика — это то что процессы мешают эффективной работе и взаимодействию. Конечно они могут мешать, если к этому относиться буквально и принимать процессы за основу, а не часть системы. От этого одна защита — культура. Об этом чуть позже.
Процессы — инструменты
Первое, что нужно сделать правильно, это система тикетов. Так же как с мониторингом, люди очень много говорят о преимуществах разных систем тикетов. И зря. Тикет-систему выбирают ту которой больше пользовались, потому что лучше знают ее возможности. Плохой ее может сделать только то, что она инициирует или поощряет плохие процессы. Что такое плохой процесс — зависит от бизнес ограничений.
Самое важное — это иметь надежно работающую тикет систему, которая двигает процессы в нужную сторону.
Пример. При мне мы перешли с RT на Jira. У Jira много преимуществ, и я бы всем рекомендовал ее для совместной работы. Однако, самая большая трудность, с который мы столкнулись при переходе, это потеря части критичных для нас возможностей, которые мы сами реализовали в RT. В RT мы могли писать в тикеты в реалтайме, что превращало тикет в что-то среднее между обычным тикетом и чатом. Это было неоценимо при последующем разборе инцидента. Еще в RT можно было скрывать записи от конечных пользователей, нам было очень трудно от этого отказаться. Мы конечно смирились, но такие фичи оказываются удивительно важны, потому что они формируют процессы и культуру.
При выборе новой тикет системы или принимая решение о переходе на другую, тщательно проанализируйте что важно для работы, а не только классно выглядит в описании. Важным может оказаться и внешний вид (серьезно, пользователи могут начать серьезнее относиться и хороший дизайн может быть важен для бренда), и возможности встроенных отчётов.
Документация
На втором месте после процессов стоит документация, и обе вещи очень тесно связаны.
Про документацию очень много разговоров, но опять, люди обычно смотрят не на те вещи. Самое важное, что нужно понимать, документация — это такой же актив. Как и о любом другом активе, о документации можно сказать:
- Если за документацией следить, все затраты многократно окупятся
- Требует вложений для поддержки (как станки на заводе)
- Если устареет — будет требовать расходов (как склад ненужных устаревших деталей)
- Если она плохого качества, то это обязательство, а не актив.
Это не предмет спора, мало кто не согласится с тем, что хорошая документация полезна. Вся суть в том как это сделать.
Документация — как было у нас
В нашей ситуации от документации, которую нам давали было мало толку (пример, разработчики пишут: ‘ситуация с потерей связи не описана, т.к. это вряд ли случится’. Ну как вы думаете, что произошло? И это еще случай, когда они позаботились о том чтобы написать что-то..), или же мы полагались на ранее зафиксированные разбирательства (к этому времени мы уже всё записывали) чтобы решить что делать в следующий раз в такой же ситуации.
Это всё было очень грустно для всех нас, и мы долго жаловались, что Дед Мороз не оставляет нам под елкой документацию, прежде чем взяли на себя ответственность за неё.
Документация — Что я сделал
Вот что я сделал.
- Я взял приоритетные инциденты за два года (такие, по которым были или могли быть звонки в нерабочее время). Таких оказалось 1700 штук.
- Я разделил их по типу проблемы
- Потом я прошёлся по каждом типу проблемы и собрал вместе шаги нужные для решения или дополнительного изучения/эскалации проблемы.
Это заняло семь месяцев моего полного вовлечения. Я был старшим спецом и компания тратила много денег на то что я сижу и пишу. И только потому что мой босс разбирался во всём меня не спрашивали стоит ли это таких затрат времени. Мне доверяли (культура, помните?!). Я думаю какие-то результаты начали появляться только через четыре месяца усилий. Я помню эти четыре месяца были очень нервными, всё мое внимание было не на основной работе, а на том что могло оказаться абсолютно бесполезной потерей моего времени и денег компании и стать постыдным провалом.
Почему я не отдал это стажеру? По целому ряду причин. Это было очень важно и никто раньше этого не делал, так что мне нужно было быть уверенным, что все сделано правильно. Я точно знал что нам нужно, и знал как написать это в том виде, который нужен как минимум мне самому. К тому же у меня был относительно большой опыт писательства (гуманитарное образование, бывший журналист), и мне нравилось думать, что это помогает мне хорошо писать.
Официально мы назвали это `Модель инцидентов` в соответствии с ITIL, но обычно говорили “рабочая дока”, “шпаргалка”, вобщем по-всякому. Это не важно. Что действительно было важно:
- По ней было легко искать и находить нужное
- Было легко понять что нашли то, что надо
- Не было дублирования
- Информации можно было доверять
Мы положили эту документацию просто текстом в тикет систему, в отдельном проекте в JIRA.
Ребята, которые занимались в компании документацией знали, что мы собирались сделать и пытались заставить нас положить всё во внутреннюю wiki. Мы твёрдо отказались и это было критично: когда документация лежит в одной системе с тикетами, то ее обновление не вызывает такого сопротивления. Простой текст быстро грузится, легко обновляется и не перегружен деталями. Мы сопротивлялись процессу, который угрожал пользе того, что мы делали.
Документация — критичность простоты
В начале мы придумали шаблон для этих моделей инцидентов, который был по своему прекрасен, подходил к любому возможному сценарию и ситуации.
В конце же оказалось, что это ненужная трата времени. У нас осталась очень тупая структура:
- Описание проблемы
- Что делать: шаги 1..N
- Дальнейшее обсуждение, ссылки на статьи
И всё. Все попытки добавить туда что-то ни к чему не привели, это или затрудняло понимание новичкам, либо создавало много бюрократии или не было применимо к достаточно большой части статей. Со временем в некоторые статьях появилась другая схема, подходящая к вопросу, список тем эволюционировал (например “введение для новичков”, статья которая говорила что нужно прочитать). Мы не могли заранее предусмотреть всего, потому что не знали что заработает, а что нет.
Если хотите — можно назвать это “гибкая методология документации”, гибкие методологии сейчас легче продвинуть (тогда это был ITIL). Повторюсь, критичное тут это простота и польза бьют всё.
Дед мороз не дарит документацию
Потратив столько времени и усилий мы поняли еще пару вещей о документации
Для начала мы перестали принимать документацию от других команд. Есть комментарии в коде — классно, есть что-то дельное в их вики — тоже здорово. Но при передаче проектов нам мы перестали слать “запросы документации”. Вместо этого мы лучше организуем разговор их команды с опытным SRE и обсудим архитектуру проекта.
Каждый раз (если только у него нет опыта админства) разработчик сосредотачивается на продукте, как его построили, как он должен работать — и это как раз то, что они тщательно оттестировали и что вряд ли сломается.
SRE, как раз наоборот, смотрит на слабые места, на то, что может пойти не так. “Что случится при потере сетевой связности? Что если база забьет весь диск? Можно ли в логах найти почему не прошла оплата?”
После этого мы идём, пишем свою документацию и даём на подпись разработчику — обычные шаги, но в обратном порядке. Часто они вносят стоящие комментарии и добавляют интересные детали.
Вторая вещь, мы заметили что наши инженеры все ещё ленятся обновлять доки, которые используют только они сами. Как будто они все ещё считают, что документацию им должен кто-то давать извне. Руководство вынуждено постоянно давить и напоминать, что это ИХ документация, не каменные таблички врученные свыше, и если её не поддерживать они не смогут делать свою работу.
Это уже проблема внутренней культуры и менялось эта вещь очень долго. Такие перемены потребовали поддержки со стороны процессов.
В итоге, по моему впечатлению, примерно 10% времени команды уходит на написание и поддержку документации. После начальных затрат в 7 месяцев большая часть этих 10% уходит скорее на поддержку чем на написание нового.
Документация — выгоды
Приведя документацию в порядок мы все ощутили выгоды намного больше, чем можно было ждать от 10% расхода времени. Приведу
- Быстрое вхождение
До того, как этот процесс пошёл мы неохотно брали малоопытных новичков. После, вхождение стало как по маслу. Помимо всего остального обучение состояло из отслеживания происходящих инцидентов и повторения за опытным наставником. Новичкам давали задания помогать в поддержке документов, чтобы они лучше увидели пробелы в своих знаниях.
- Улучшенное обучение
Доки стали использовать как ресурс для выявления требований по обучению сотрудников. Это привело нас к списку инструментов и техник, которые можно было рекомендовать инженерам для изучения.
- Меньше стресса из-за простых эскалаций
Это очень важно. Раньше, когда у нас были пошаговые модели инцидентов, решение эскалировать было очень нервным. Некоторые инженеры заработали плохую репутацию за ранние эскалации и чувствовали себя неуверенно, боясь “пропустить что-то очевидное” прежде чем позвонить дежурному лиду в нерабочее вермя. Но SRE также вызывали на ковёр за то, что они НЕ эскалировали вовремя!
Новые модели инцидентов решили это. Довольно быстро первым вопросом спеца принимающего эскалацию стало “по модели инцидента прошли?”. Если это было сделано, и при этом пропустили что-то очевидное, то пробелы в модели быстро выявлялись и устранялись. Так спецы, на которых эскалировали проблемы сами сами стали заниматься обновлением и улучшением доки. Круг создания доки замкнулся.
- Больше порядка.
Очевидная значимость документации помогла привести в порядок и отношения между командами. SRE раньше считалась самой “громкой” командой — они часто затевали споры и вообще были очень общительными, что вполне естественно. Нам приходилось полагаться на другие команды чтобы покрыть множество технических компетенций, разбираться с руководителями, у которых часто не хватало технических знаний, и распространять свои знания и культуру было критичным для нас.
С течением времени команда становилась всё тише и тише, частично из-за перехода на чаты, большего времени на удалёнке, с командами из разных стран, но также и из-за того факта, что существенная часть работы превратилась в рутину: пройтись по модели инцидента, если всё сделано или что-то непонятно — эскалировать на старшего.
- Автоматизация
Четкое описание, как мы его сделали, было хорошим залогом для дальнейшей автоматизации в софте.
Отследив, какие тикеты были связаны с разными моделями инцидентов мы точно знали, на чем лучше сфокусировать усилия. Мы писали скрипты чтобы прочёсывать логи в фоне, разбирать сложные проблемы быстрее и проще, даже автоматизировали ответы клиентам (“Проблема вызвана изменениями, сделанными администратором приложения, пользователем XXX’), и еще кучу всего.
Эти автоматизации привели к созданию инструмента, который мы написали для себя на основе pexpect: http://ianmiell.github.io/shutit/. Но это уже другая история. Вобщем, стоило начать и мы пришли к циклу постоянных улучшений.
Опять о процессах
Если у вас уже есть такой актив, что вы сделаете чтобы предотвратить его инфляцию со временем? Вот где критично использовать процессы.
Два процесса были самыми важными для того, чтобы убедиться в гладкой работе:
Процессы — диагностика
От 5% до 10% времени у нас тратилось на первичную диагностику. Исправить этот процесс тоже было не быстро, но в результате мы достигли хорошей экономии:
- Уменьшили количество шагов до минимума полезных
Большой соблазн в том чтобы запихать побольше в чеклист диагностики, но жизненно важно ставить пользу выше всеохватности. Каждый недостаточно полезный шаг начнут иногда пропускать, забывать и потом его вовсе станут игнорировать.
- Внимание на сокращение расходов
Поиск дублирования, нахождение связанных моделей инцидентов, быстрая обратная связь с клиентом и ранняя эскалация — всё это существенно снизило затраты на обработку тикета в среднем.
И еще это спасло инженеров от лишних переключений контекста по вопросам, которые им задавали пока они были заняты чем-то другим. Это сложно оценить, но в целом мы стали обрабатывать больше инцидентов меньшим количеством людей и меньше напрягаясь. Старшее руководство, а главное клиенты, оценили.
Запись деталей также помогла экономить время, например, инженер к которому пришёл тикет после начальной диагностики мог видеть что именно искал предыдущий человек по этому тикету в базе и что можно улучшить в документации и процессе. Это еще дает возможность более опытным людям понять и оценить качество работы по диагностике.
- Ревью диагностики
Опытным товарищам нужно периодически делать ревью процесса диагностики, чтобы убедиться что он применяется достаточно эффективно.
Когда я перешёл в другую команду администрирования (с областью в которой я разбирался намного меньше), я смог сократить очередь инцидентов в 2 раза примерно через 3 дня, просто применив эти техники. Процесс диагностики уже был, но ему не следовали осмысленно и контролируемо, и был отдан младшему, не самому способному сотруднику. Большая ошибка. Первичной диагностикой должен заниматься или хотя бы контролировать иногда кто-то с хорошим опытом. Хотя это и выглядит механической рутиной, тут нужно принимать много важных решений, зависящих от опыта в данной сфере.
И да, я был новым начальником, и я начал с того, что потратил первую неделю занимаясь “ерундовой” задачей первичной диагностики инцидентов. Таким важным я это считаю.
- Чередуйтесь в диагностике
Так как никто не хотел заниматься первичной диагностикой мы начали чередоваться по неделям. Это дало немного стабильности и целостного восприятия, но не давало забить мозги инженера постоянно делающего одно и тоже по много раз подряд.
Процесс — пост-инцидент разбор
Зеркальное отображение первичной диагностики — это “пост-инцидентное ревью”. Каждый тикет разбирался опытным членом команды. Это было существенно важно и занимало около 5% усилий.
Заполнялась стандартная форма и любые рекомендации добавлялись в беклог “улучшений”, который можно было приоритизировать. Так мы могли, когда нам было нужно, определить численно величину технического долга.
Культура
Я много раз сказал про культуру, этот вопрос всегда возникает когда пытаешься что-то изменить, потому что культура лежит в основе всех концепций и на ней основываются все наши действия.
Также я говорил, что люди часто фокусируются на “неправильных вещах”. Я вижу, что люди смотрят на технологии и инструменты, а не на культуру. Да, инструменты и технологии важны, но если их неправильно использовать они хуже чем просто бесполезны. Даже если у вас самые лучшие клюшки для гольфа в мире, но вы не знаете как правильно бить и вообще играете в бейсбол, то толку от них немного.
Культура требует намного больше вложений, чем технологии (я больше чем полгода потратил на написание документации, помните?) Когда культура в порядке люди будут сами находить правильные инструменты и технологии тогда, когда они понадобятся.
Если стоит выбор на что потратить время и деньги — всегда вкладывайте в первую очередь в культуру. Я пожертвовал хорошей частью бюджета, но настоял на увольнении “несоответствующего” члена команды, и это оказалось моим лучшим решением, как нового руководителя. Команда прямо расцвела после его ухода, как только исчезло давление от его агрессии, и начала делать вещи которые раньше не получались.
Мы смогли создать настолько эффективную команду с таким низким бюджетом, что кадровики звонили и ругались, что мои запросы “невозможны в принципе”. Но фокусируясь на правильном поведении, инвестируя время в людей, которых мы нашли и построив хорошие процессы мы получили невероятно эффективную и лояльную команду, создающую большие и лучшие вещи для компании и вне ее (в основном для компании, конечно).
Политика
И немного о политике. Всегда приходится выбирать. Вряд ли вы получите все ресурсы, которые нужны, так что отказывайтесь от того, что все равно не выйдет.
Да, вам нужны решение для мониторинга, хорошая документация, обученные сотрудники, лучшее тестирование… все вместе не будет, если только вы не владеете печатным станком, так что выбирайте самое важное и решайте что-то одно. Если начнете заниматься всем вместе — скорее всего придете к провалу.
После процессов и документации я начал разбираться с проблемой воспроизводимости окружения. Так я докопался до Docker и полной смене карьерного пути. Об этих вещах я говорю здесь и вот здесь.
Вопросы??
Я в твиттере: @ianmiell
или LinkedIn
Моя книга Docker in Practice:
Get 39% off with the code: 39miell
Ранее статья была опубликована тут.