Войти в систему
Войти с помощью соц. сетей:
Автор — Эндрю Стриблхилл
Под редакцией Кавиты Джулиани
Эффективное управление во время аварии является ключом к минимизации причиненного ущерба и скорейшему восстановлению нормальной работы. Если вы не отрепетируете собственный ответ на потенциальные инциденты, теоретические механизмы управления инцидентами в реальных ситуациях могут пойти насмарку.
В этой главе анализируется пример инцидента, который выходит из-под контроля из-за бессистемного управления, описывается корректный подход к инцидентам, а также рассматривается итог того же инцидента в случае с применением отлаженных методов управления.
Поставьте себя на место Мэри, дежурного программиста фирмы. Пятница, на часах два часа пополудни, и тут пейджер внезапно взрывается. Мониторинг методом черного ящика говорит, что ваш сервис прекратил обработку какого бы то ни было трафика во всем дата-центре. Вздохнув, вы отставляете чашку с кофе и принимаетесь решать проблему. Через несколько минут приходит оповещение об остановке второго дата-центра. Затем отказывает уже и третий из ваших пяти дата-центров. Ситуация усугубляется тем, что объем трафика превосходит возможности оставшихся дата-центров, и это приводит к перегрузке. Когда вы это обнаруживаете, сервис уже оказывается перегружен и больше не способен отвечать на запросы.
Вы напряженно всматриваетесь в файлы журналов, и кажется, что это продолжается уже целую вечность. В них тысячи строк, и, судя по ним, ошибка кроется в одном из недавно обновленных модулей, поэтому вы решаете вернуть серверы к предыдущей устойчивой версии. Когда выясняется, что откат не помогает, вы звоните Жозефине, которая написала большую часть кода агонизирующего в данный момент сервиса. Напомнив вам, что в ее часовом поясе сейчас полчетвертого утра, она все же сонным голосом соглашается авторизоваться и взглянуть. Ваши коллеги Сабрина и Робин начинают копаться в проблеме с собственных терминалов. «Мы просто смотрим», — говорят они.
Тем временем один из служащих позвонил вашему боссу и рассерженно требует ответа на вопрос, почему ему не сообщили о «полной катастрофе этого жизненно необходимого для работы сервиса». Вице-президенты порознь донимают вас по поводу срока устранения проблемы, постоянно спрашивая: «Как это могло случиться?» Вы бы рады были отнестись к их вопросам со всем вниманием, но это потребовало бы когнитивных усилий, которые вы бережете для работы. Они вспоминают свой прежний опыт разработки и высказывают бесполезные советы вроде: «Увеличь размер этой страницы!» — которые тем не менее нельзя оставить без внимания.
Проходит время, и два оставшихся центра обработки данных отказывают окончательно. Не ставя вас в известность, сонная Жозефина звонит Малколму. У него неожиданно возникает блестящая идея: что-то насчет привязки потоков к процессорам. Он убежден, что сможет оптимизировать процессы на оставшихся серверах (в промышленной среде!), если поставит на них вот это простое изменение, — и делает это. В течение пары секунд серверы перезапускаются, принимая изменения. А затем умирают.
Заметьте, что в вышеизложенном сценарии каждый исполнял свои обязанности так, как понимал их. Почему же все пошло так плохо? Этот инцидент вышел из-под контроля из-за нескольких типичных неблагоприятных факторов.
Мы стремимся набирать таких людей, как Мэри, из-за их технического мастерства. Поэтому неудивительно, что она была занята внесением функциональных изменений в систему, мужественно пытаясь решить проблему. Мэри была не в том положении, чтобы более масштабно думать о минимизации последствий аварии, поскольку ее непосредственная техническая задача оказалась непосильной.
По той же причине Мэри была слишком занята, чтобы поддерживать четкий обмен данными. Никто не знал, какие действия предпринимают его коллеги. Руководство было в ярости, клиенты дезориентированы, а прочие инженеры-программисты, которые могли бы подставить плечо в поиске и исправлении ошибки, не были задействованы в полной мере.
Малколм внес изменения в систему из лучших побуждений. Он, однако, не согласовал свои действия с коллегами, даже с Мэри, которая технически была ответственна за устранение неполадок. Его действия сделали эту и без того плохую ситуацию еще хуже.
Навыки и методы управления в критических ситуациях существуют для того, чтобы направлять силы мотивированных индивидуумов. Используемая в Google система управления в критических ситуациях основана на системе управления инцидентами (Incident Command System, ICS) — системе концепций, рекомендаций и стандартов, отличающейся прозрачностью и масштабируемостью.
Правильно спроектированный процесс управления инцидентами имеет следующие особенности.
Необходимо убедиться, что каждый участвующий в разрешении инцидента знает свою роль и не заходит на чужую территорию. Это может показаться парадоксальным, но четкое разделение обязанностей предоставляет отдельным лицам больше автономии, поскольку не приходится угадывать поведение коллег и подстраиваться под них.
Если нагрузка на отдельного члена команды становится чрезмерной, ему нужно запросить у ответственного за планирование больше исполнителей. Те, в свою очередь, тоже могут передать работу следующим сотрудникам, и это может повлечь за собой появление субинцидентов. Или же выполняющий функции «лидера инцидента» может передать различные компоненты системы коллегам, которые затем сообщают лидеру результаты исследования.
Есть несколько вполне обособленных ролей, которые следует распределить между лицами, участвующими в работе над инцидентом.
• Управление инцидентом. «Начальник штаба» контролирует общее состояние инцидента, формирует команду для работы с инцидентом и распределяет обязанности в соответствии с текущими потребностями и с приоритетом задач. На практике он же исполняет и все нераспределенные функции. При необходимости он может устранять препятствия, которые мешают оперативной группе работать наиболее эффективно.
• Оперативная группа. Лидер оперативной группы взаимодействует с «начальником штаба» и работает над разрешением инцидента, применяя имеющиеся средства для выполнения поставленных задач. Только оперативная группа может обладать правом на внесение изменений в систему на протяжении всего инцидента.
• Информирование. Лицо всей команды. В его обязанности непременно входит держать в курсе происходящего (обычно посредством электронной почты) всю команду и иных заинтересованных лиц, а также, например, поддерживать актуальность и достоверность документации об инциденте.
• Планирование. Цель планирования — оказывать оперативной группе поддержку, занимаясь более длительными делами, такими как регистрация найденных ошибок, заказ обеда, планирование и организация передачи задач между исполнителями, а также отслеживание и фиксацию аномалий в системе, чтобы ее можно было вернуть в исходное состояние после разрешения инцидента.
Заинтересованные стороны должны знать, где они могут общаться с «начальником штаба». Во многих ситуациях уместно компактное расположение всех членов команды в месте, обозначенном как центр управления. Другие команды могут предпочесть работать за собственными столами, отслеживая обновления по инциденту посредством электронной почты или IRC (Internet Relay Chat).
По опыту корпорации Google, IRC приносит огромную пользу в реагировании на инциденты. IRC работает очень надежно и может быть использован для протоколирования всех переговоров в ходе работы, чем оказывает неоценимую помощь в удержании в памяти всех подробностей о происходящих в системе изменениях. Мы написали боты, которые регистрируют относящийся к инциденту трафик (что пригодится для последующего изучения в ходе «разбора полетов») либо фиксируют такие события, как оповещения в канале. IRC — это также удобное средство общения, способное координировать территориально распределенные команды.
Одна из наиболее важных обязанностей «начальника штаба» — ведение обновляемого документа об инциденте и обеспечение его актуальности. Он может существовать в виде редактируемой веб-страницы, но лучше всего — в виде документа с коллективным доступом, редактируемого несколькими людьми одновременно. Большинство наших команд используют Google Docs, хотя сама SRE-команда Google Docs пользуется сервисом Google Sites: в конце концов, если система зависит от программного средства, которое вы и пытаетесь исправить в рамках данного инцидента, то вряд ли она в это время будет работоспособна.
В приложении В вы найдете образец документа об инциденте. Обновляемый документ может выглядеть неряшливо, но он должен быть функциональным. Использование шаблонов должно облегчить создание подобной документации, а запись наиболее важной информации в самом верху документа делает его более практичным. Сохраните его для последующего «разбора полетов» и, если необходимо, для метаанализа.
Принципиально важно, чтобы функции «начальника штаба» были полностью и однозначно переданы в конце рабочего дня. Если вы передаете управление кому-то с другим местоположением, сообщите ему об этом посредством телефонного или видеозвонка. Как только новый начштаба полностью введен в курс дел, покидающий пост должен четко обозначить передачу, явно говоря: «Сейчас ты управляешь инцидентом, понятно?» — и оставаться на связи, пока не получит такого же четкого подтверждения того, что пост принят. Передача управления должна быть доведена до сведения других лиц, работающих над инцидентом, чтобы в любое время всем было известно, кто возглавляет работы по управлению инцидентом.
Посмотрим, чем обернулась бы та же ситуация, если бы к ней применили принципы управления инцидентами.
На часах два пополудни, и Мэри пьет третью чашку кофе за день. Ее застает врасплох резкий сигнал пейджера, и она залпом допивает напиток. Возникла проблема: центр обработки данных прекратил обслуживание трафика. Мэри начинает разбираться. Вскоре приходит новое оповещение: вышел из строя второй из пяти центров обработки данных. Таким образом, ситуация развивается очень быстро, и это говорит, что пора воспользоваться системой управления инцидентами.
Она подтягивает Сабрину. «Ты сможешь принять управление?» Кивнув в знак согласия, Сабрина получает от Мэри краткое изложение нынешнего положения дел. Подробности она заносит в письмо, которое рассылает по заранее подготовленному списку контактов. Сабрина понимает, что пока не может оценить последствия аварии, и просит содействия Мэри. Та отвечает: «Пользователей уже должно было затронуть, но будем надеяться, что не потеряем и третий центр». Сабрина записывает ответ Мэри в обновляемый документ инцидента.
Когда приходит третье оповещение, Сабрина видит его в отдельной ветке IRC и дублирует информацию в цепочке электронных писем. Письма держат вице-президентов в курсе ситуации без заваливания лишними подробностями. Сабрина просит уполномоченного по связям с общественностью начать составление обращений к пользователям, а затем обращается к Мэри, чтобы узнать, не следует ли им связаться с дежурным разработчиком (в данный момент это Жозефина). Получив утвердительный ответ от Мэри, Сабрина подключает Жозефину к работе.
К тому времени как Жозефина авторизуется в системе, уже вызвался помочь и Робин. Сабрина напоминает Робину и Жозефине, что они должны уделять первоочередное внимание любым задачам, которые поставит им Мэри, и держать Мэри в курсе любых дополнительных действий, которые они предпринимают. Робин и Жозефина быстро знакомятся с текущей ситуацией, прочитав документ инцидента.
Тем временем Мэри уже попробовала вернуть предыдущую версию сервиса (бинарные файлы) и убедилась, что это не помогло. Она быстро пожаловалась на это Робину, и тот сообщил в IRC о неудаче этой попытки исправления. Сабрина скопировала эту информацию в обновляемый документ о состоянии инцидента.
В пять часов вечера Сабрина начинает искать персонал, который взял бы на себя работу над инцидентом, поскольку она и ее коллеги собираются идти домой. Она обновляет документ об инциденте. В 5:45 проходит короткая телефонная конференция, в результате все владеют ситуацией. В шесть вечера члены команды передают обязанности коллегам в следующем офисе.
Следующим утром Мэри вернулась на работу и узнала, что ее коллеги по другую сторону океана, приняв эстафету, локализовали проблему, позаботились о минимизации ущерба, закрыли инцидент и начали работать над отчетами. Проблема решена. Мэри заваривает свежий кофе и принимается за планирование структурных улучшений, чтобы аналогичные проблемы не побеспокоили команду снова.
Лучше объявить об инциденте как можно раньше, найти простое решение и закрыть инцидент, чем часами развертывать структуру управления инцидентами в условиях нарастания проблемы. Определите четкие условия для объявления инцидента. Моя команда руководствуется следующими общими правилами. Если выполняется любое из этих условий, событие является инцидентом.
• Вам необходимо привлекать вторую команду, чтобы решить проблему.
• Перебой в работе заметили клиенты.
• Проблема не решена даже после нескольких часов сосредоточенной работы.
Компетентность в управлении инцидентами быстро утрачивается, если не находит применения постоянно. Но как программистам поддерживать на должном уровне свои навыки по управлению инцидентами — работать с большим их количеством? К счастью, принципы и методы управления инцидентами можно применять к другим функциональным изменениям, которые требуют задействовать несколько команд, особенно в разных часовых поясах. Если вы используете эти методы как привычную часть процедур управления изменениями в системах, вы легко примените их и при возникновении настоящего инцидента. Если ваша организация проводит тестирование аварийного восстановления (если нет, то начните, это весело: см. [Krishan, 2012]), то управление инцидентами должно быть частью этого процесса. Мы часто проводим ролевую игру — реагирование на критическую ситуацию, которая уже была разрешена (возможно, коллегами на другой площадке), чтобы лучше освоить управление инцидентами.
Итак, предварительно выработав стратегию управления инцидентами, имея структурированный, гибко масштабируемый план и регулярно применяя его на практике, мы смогли существенно сократить среднее время восстановления и снизили стрессовую нагрузку на персонал в критических ситуациях. Внедрение аналогичной стратегии могло бы быть полезно для любой организации, озабоченной обеспечением бесперебойной работы.
| Практические рекомендации по управлению инцидентом Расставляйте приоритеты. Остановите развитие аварии, возобновите работу сервиса и сохраните данные для последующего анализа истинных причин аварии. Готовьтесь заранее. Заранее разрабатывайте и документируйте ваши методы управления инцидентами, согласовывая их со всеми участниками. |
| Доверяйте. Предоставьте всем участникам работ полную самостоятельность, но в рамках отведенных им ролей. Используйте самоанализ. Уделяйте внимание своему эмоциональному состоянию во время работы над инцидентом. Если вы начинаете впадать в панику или чувствуете перегруженность, запросите помощь. Рассматривайте альтернативы. Время от времени взвешивайте варианты и анализируйте: целесообразно ли продолжать работу над текущей задачей или же стоит взяться за другую, более неотложную. Практикуйтесь. Применяйте эти подходы постоянно, чтобы это вошло в привычку. Проводите ротацию. В прошлый раз вы были начальником штаба? Тогда сейчас возьмите на себя другую роль. Стимулируйте всех участников команды ознакомиться с каждой ролью. |
Более ранняя версия этой главы появилась в виде публикации в ;login: (апрель 2015 года, выпуск 40, № 2).
Подробнее см. .
Стоит отметить, что в обоих примерах в этой главе рассматриваются только первые шаги реагирования на возникшую аварию, а ее причины и действия по ликвидации последствий остаются за кадром. — Примеч. пер.
Войти с помощью соц. сетей: