Казалось бы, такое простое действие: взять да восстановиться из бекапа, если где-то сломалось. Текущий уровень развития софта позволяет это cделать буквально в несколько кликов - и вы восхитительны. Возможно, даже никто не заметит, что была какая-то авария.
Но нет! Нет препятствий патриотам, как говорили в одном прекрасном фильме. Даже во время послеаварийных работ можно натворить такой дичи, что завтра ваша трудовая будет прибита двухсотым гвоздём к забору у проходной, а слава о ваших деяниях будет ещё долгим эхом ходить по просторам IT вселенной.
И вот о том, как не овеять себя славой самого могучего специалиста во веки веков, мы сегодня и поговорим. Шесть очевидных и не очень поводов задуматься. И да, при чтении не забывайте поднимать табличку "Сарказм" и помните - всё написанное ниже основано на реальных случаях.
Ты админ ты лучше знаешь, чего им надо!
И никто не вправе тебе указывать, в какой последовательности, насколько срочно и что именно надо восстанавливать. Да, можно прикинуться вежливым и для галочки обойти руководителей других отделов, чтобы составить план восстановительных работ на случай аварии, но зачем? Генеральный не шарит и подпишет что угодно, а на местах будут перетягивать одеяло на себя. Продавцы скажут, что их база самая важная. На складе будут твердить, что час без отгрузок - минус выручка за неделю. А на производстве так и вовсе удивятся такому банальному вопросу.
Нет, можно конечно воодушевиться и собрать их всех вместе, чтобы выстроить приоритеты и понять критичность конкретных сервисов для бизнеса, потом подписать SLA и выстроить строгий план. Но зачем? IT - это твоя зона ответственности, и нечего другим туда свой нос совать. Особенно тем, кто не шарит.
Этим приложением пользуется всего десять человек? Да это явно ерунда какая-то и не может быть критически важным компонентом производственной цепочки. А вот файловая шара на несколько терабайт всегда была в почёте. Кого ни спросишь, все там что-то хранили, и совершенно очевидно, что после контроллера домена первым делом надо поднимать именно её. Ну и почту, наверное. Остальные подождут, ничего страшного не случится.
Не забивай голову мануалами. Всё знать невозможно
В конце концов вы за что деньги платили? Ладно бы софт был бесплатный, а железо собирал ты сам из подручных компонентов. В таком случае ещё можно как-то оправдать недельное вкуривание мануалов по настройке и оперированию. Но ты сначала купил софт для бекапа по цене чугунного моста, а потом ещё и здоровую СХД для интеграции, которая сожрала под два годовых бюджета. А сверху ещё и сеть отдельную проложил. Поэтому любому дураку понятно, что ничего сложнее Quick Start Guide читать не надо. Все эти толстенные мануалы, конечно, очень важны и полезны, но голова-то не резиновая. Нельзя в неё пихать всё подряд.
Сделать первичную настройку - это святая обязанность любого поставщика, а если что-то и изменится, то там внутри всегда всё интуитивно, а разработчики предусмотрели защиту от любых попыток отстрелить себе ногу. Да и на случай, если что-то пойдёт не по плану, всегда можно позвонить в сапорт. Или письмо написать. Или даже найти чат в телеге, где тебе с радостью помогут буквально сразу.
Также не вздумай вникать в подкапотное пространство тех приложений, которые понаставили на твои горячо любимые сервера. БД админ что-то там говорил о уже настроенных бекапах сторонним приложением? Ай, да не важно. Два бекапа всегда лучше, чем один. Тем более, что тебе надо настроить бекап вашего кластеризованного почтовика. Хотя чего там настраивать? Он же в кластере, и чего ему будет. Достаточно бекапить любую ноду и вся наука. Лучше пойти и переносом инфы на pass-through диски заняться.
Так что ничего сложнее операционки на уровне продвинутого сисадмина в памяти держать не надо. Тебе за это не платят.
Сейчас главное восстановиться, а куда и как - не суть важно
Если авария уже случилась, то первейшая наша цель - это восстановить данные и запустить критичные сервисы. Поэтому наш девиз в это тревожное время: Вижу цель, не вижу препятствий. Сейчас главное - скорость и быстрота реакции. Клик-клик - и вот уже бекап европейского сервера разворачивается где-то под Тверью. Не важно, что там дохлая площадка на полтора сервера, главное - побыстрее бы. Бекапы ведь именно там, значит и восстановится быстрее. Персональные данные европейцев? Ой, ну кому какая разница сейчас до ваших далёких GDPR и прочего. Нам же восстановиться надо. Хостинг в пять раз дороже, чем упавший? Да какая разница, потом мне ещё спасибо скажут за быстроту реакции. Мало места на дисках? Так вот это явно ерунда какая-то, можно и не восстанавливать. Сейчас главное - это восстановить прод!
Один для всех и все для одного!
Единые правила бекапа для всей инфраструктуры - это абсолютно нормально. Слабохарактерные здесь могут начать возражать, что бывают системы, выход из строя которых будет фатален, и для их защиты надо строить active-active кластера, делать резервирование и продумывать варианты репликации. Например, взять ту же сеть. Вы представляете, сколько будет стоить сделать двойное её резервирование? Это же надо рядом с одной сетью построить вторую такую же. А ведь от кривых рук админов мы и так защищены постоянными бекапом конфигов, чтобы иметь возможность в любой момент откатиться. Если сгорит какая-то sfpшка, то самый молодой твёрдо знает, в какой магазин бежать за новой, а наши поставщики готовы по звонку привезти нам хоть новое ядро сети. Ну а за те полчаса, пока они едут, ничего страшного не случится.
Хорошо, возразят другие, это было про совсем уж критические системы, без которых встанет натурально всё. А что с теми, где действительно можно часик подождать? Например, почтовик или сайт, на который можно быстро выкатить извинительную заглушку? Здесь главное - тоже не поддаваться на уговоры параноиков и не начать городить Active-Passive системы. Там ведь есть гора своих проблем с синхронизацией, например. Можно, конечно, построить систему, которая будет делать снапшоты по расписанию и позволять быстро откатываться с минимальными потерями. Но это опять деньги на лицензии и железо, работающее вхолостую. И по большому счёту это риски теоретические и защищающие от авось.
Поэтому, чтобы не тратить лишние деньги и время, всегда достаточно использовать единое решение, в котором есть максимум функционала, пусть даже оно и не защищает от всех рисков. Ибо всем известно, что множество точек отказа - это всегда хуже, чем одна.
Disaster Recovery Plan Шредингера
С этим прекрасным документом есть ровно две противоположные проблемы. У одних его нет, другие его распечатывают, подписывают и прячут в сейф. В итоге как себя вести при аварийной ситуации, не знают ни первые, ни вторые. Первые оправдывают себя тем, что инфраструктура - вещь живая и постоянно меняется, а значит, придётся постоянно вносить изменения, согласовывать их, и так далее. Так что гораздо лучше будет не морочить себе голову бумажной волокитой, а довериться своим знаниям и не мешать людям работать. Они же профессионалы!
Вторые бумажной работы не боятся, тщательно всё документируют и в случае аварии шаг за шагом следуют плану. Ибо, как известно: если план подписал генеральный, значит, вся ответственность будет на нём, а сам план должен неукоснительно соблюдаться. Главное, чтобы этот документ напоминал локальную копию википедии: максимально подробные схемы включения абсолютно всего оборудования, схемы зависимости приложений, порядок загрузки машин, через какой порт кто с кем связывается, многочисленные проверки настроек и базовых тестов после включения. Словом, бюрократия 80 уровня. А если с последнего согласования были изменения или в середине отработки сценария всё пошло совсем не так, как описано, то это уже издержки производства. Виноватых найдём и покараем, главное - строго следовать плану. Больше бумаги чище все места.
Ходят слухи, что есть ещё вариант посредине, и некоторые не только пишут пошаговые инструкции, но и разрешают сотрудникам руководствоваться здравым смыслом при выполнении любых действий. А совсем мифические персонажи так ещё и тренинги проводят, наживую отключая целые системы и симулируя типичные инфраструктурные проблемы. Правда, неясно, кто таких маньяков на работу берёт.
Каждый должен знать своё место
Будет настоящим преступлением и растратой денег работодателя позволять сотрудникам отвлекаться от их основной работы в рамках трудового договора и вникать в деятельность коллег. Во-первых, это отвлекает самих коллег, не позволяя им трудиться в полную силу. А во-вторых, сам сотрудник тоже будет постоянно отвлекаться от своей работы, тем самым повышая шансы ошибиться. И в итоге у нас два человека, не работающие в полную силу. Поэтому совершенно недопустимо, чтобы условный сетевик плотно общался с условным инженером группы виртуализации. Так у вас ни сети нормальной не будет, ни внятно работающих виртуалок. Если у них возникает какой-то общий проект, замечательно оформляется запрос от одной команды к другой, формулируется ТЗ и работа ведётся строго по нему. А бесконтрольный обмен знаниями - это путь к хаосу.
И главное, от чего вас это спасёт: в случае аварии, если на месте не будет профильного специалиста, никто и не додумается залезать на его участок. Даже если он будет руководить действиями удалённо, лучше уж подождать пока он приедет, чем сломать всё ещё больше.
Вот такие вот шесть вредных советов.
Возможно, они и звучат банально, но никогда не будет вредным лишний раз проверить себя и убедиться, что в случае аварии вы не оплошаете и с блеском выйдете из ситуации.
А какие вредные советы для коллег добавили бы вы?
