Как написать аварийный план

Памятка по составлению аварийного плана

Многие из вас на прошлой неделе задумались о своей IT-инфраструктуре. Если ещё недавно многие считали, что “миграция в облако” гарантированно спасёт от потери данных и от длительных простоев (поскольку админы облаков заведомо умнее тех админов, которых вы планируете нанимать дешевле рынка)... Что бэкапы особо не нужны, потому, что потеря VPS где-то в облачной инфраструктуре - это что-то маловероятное и - уж точно вряд ли можно потерять несколько VPS, вроде, размещённых на разных физических серверах. 

Теперь же, глядя на то, как датацентр OVH в свою очередь “мигрирует в облака” (те, которые на небе), многие технические директора задумались о том, что бы они делали в такой ситуации, в которой оказались их коллеги, имевшие несчастье выбрать OVH своим хостером. 

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

Сразу отметим. Есть два понятия: DRP -- план восстановления после катастрофы и BCP -- план непрерывности бизнеса. Обычно их принято разделять и DRP писать только про инфраструктуру. Но если у вас сейчас нет ничего, то до разделения на эти два понятия вы ещё просто не доросли. Давайте то, о чём мы сейчас говорим, будем называть словосочетанием Аварийный План. Вам предстоит в него внести элементы и DRP, и BCP.

Примечание: вполне возможно, что покопавшись в ящиках стола, вы найдёте некий план, составленный интегратором за большие деньги и пылящийся от аудита к аудиту. Сохраните его, он вам ещё понадобится. А пока давайте просто начнём. Хоть как-нибудь.

Как должен выглядеть аварийный план

Главный секрет того, за что вы сейчас взялись: Аварийный план может выглядеть абсолютно как угодно. Так, как вам будет удобно. Тяжеловесный бюрократический документ вы напишете, когда вас заставят требования комплаенса (а если он уже написан, измените с учётом работающего плана). А сейчас вы можете сделать табличку в экселе (рекомендуем), нарисовать mind-map на маркерной доске или написать текст в ворде. Требования два: 

1. План должен быть понятным. Что произошло -- кому -- что делать. Каждый сотрудник должен иметь возможность посмотрев в план понять, что он делает.
2. План должен быть реализуем. Об этом мы ещё поговорим в разделе про тренировки.

Опыт нам подсказывает, что всё это слова без конкретных примеров и форм, поэтому будем ориентироваться на простую эксельку.

Что должно быть в аварийном плане

Самый простой план, который можно только придумать, должен состоять из нескольких полей. 

К этой иллюстрации нужны некоторые пояснения. Во-первых, метод указания времени мы берём у взрослых: время аварии “Ч” плюс 30 минут, час и т.п.

Во-вторых, как несложно заметить, к плану нужен справочный материал. Представьте себе, что за него сейчас взялся человек, который впервые его видит. Кто такой “Петя”, как ему звонить? А если я сегодня вместо Пети, где взять доступы, что за аккаунты у провайдера и т.д. и т.п.

Чтобы не загромождать лист с планом, это всё надо вынести на вторую вкладку и сделать ссылки.

Как написать аварийный план

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

Как придумывать эти события?

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

Причём, как в любом мозговом штурме, не надо бояться предлагать бредовые события. Даже если в голову будет приходить “вторжение инопланетян”, вы не забудете сходное со вторжением по бредовости (с вашей нынешней точки зрения) исчезновение гитхаба вместе с вашим кодом. Причём причины могут быть разные от санкций против вашей страны и последующего бана аккаунта, до пожара в датацентре гитхаба с невозможностью что-то восстановить из бэкапов (у Gitlab уже нечто подобное было). Вам не важно, что именно произошло с гитхабом. Вам надо просто записать это в риски. Вот так:

Для кого?

Кто те люди, перечисленные в третьем столбце нашего аварийного плана? В первую очередь это, конечно, ваши коллеги - технари. Но задумайтесь, как будет работать ваша компания, когда произойдёт авария? Что будет отвечать на вопросы техническая поддержка? У кого узнавать информацию по времени восстановления? Что будет говорить пресс-служба, осаждаемая СМИ? Как часто и кому будет звонить директор и спрашивать "ну когда уже, когда?".

А если у вас не IT-компания, то как будут работать те люди, которые в одночасье лишились своих рабочих инструментов.

Тут вам предстоит внести в план элементы BCP и написать аварийную инструкцию для каждого из них.

Всё?

Можно убрать план и следующий раз достать его, когда случится катастрофа? 

Можно и так, только работать вы по нему не сможете, потому что к тому моменту он безнадёжно устареет. Бэкапы не откроются (да и вообще выяснится, что они не делались последний год), люди, перечисленные в плане, -- уже давно не с вами, аккаунты устарели и т.д. и т.п. Поэтому в вашей эксельке нужна ещё одна самая важная вкладка.

Сюда вам придётся придумать и записать задачи, которые позволят плану и всему, что с ним связано, оставаться актуальным. Актуализацию самого плана. Проверку бэкапов. 

Тренировки

Ну и последнее. 

Когда вы напишете план -- попробуйте что нибудь сломать (лучше -- не по настоящему). Вы удивитесь, но окажется, что ваш план полное барахло и к реальной жизни не применим. Это нормально. Исправьте его по результатам. А потом ещё раз и ещё. Только регулярным решением аварий из плана вы достигнете идеала.