Как правильно вносить изменения в IT-инфраструктуру.

Думаю что ни для кого не представляет секрета, что работа большинства системных администраторов в небольших компаниях практически никак не формализована и не документирована. С одной стороны вроде бы и размах задач не тот и времени в обрез, а с другой все оказывается завязано на одного единственного человека, который "вроде-бы знает, как это все работает". Особенно ярко данная проблема проявляется при необходимости внести какие либо изменения в инфраструктуру.

Онлайн-курс по устройству компьютерных сетей
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

Поводом для написания данной заметки послужил вполне реальный случай. Администратор одного из наших клентов вносил изменения в движок корпоративного сайта, попутно сделал какие-то настройки на сервере и обновил его. После перезагрузки сервер перестал отвечать на сетевые запросы. Кроме сайта на этом сервере работало корпоративное web-приложение и работа фирмы оказалась практически парализована.

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

Ситуация, что и говорить, малоприятная, получить серьезный сбой на "ровном месте" - это очень плохой показатель работы админа, который, как правило, сказывается на его зарплате. Можно ли было этого как-либо избежать? Можно. Для управления IT-инфраструктурой давно существует библиотека ITIL, которая содержит набор методик и практических подходов по управлению информационными технологиями. Конечно, внедрение ITIL в работу небольшой фирмы (да и средней тоже) - это что-то из области фантастики, а вот взять на вооружение отдельные моменты можно и нужно.

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

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

Гораздо хуже, если вы планируете внедрение с привлечением сторонних специалистов, в этом случае выявление таких "неожиданных моментов" способны серьезно увеличить сроки и стоимость проекта, либо вообще поставить под угрозу его реализацию.

Итак. Любое изменение инфраструктуры должно быть спланировано и задокументировано. Это позволит грамотно оценить риски и провести изменения с минимальным влиянием на работу предприятия, даже если они окажутся неудачными. Мы предлагаем следующий способ документирования изменений:

Описание изменений.

В данном пункте постарайтесь коротко и ясно изложить, для чего предназначено данное изменение, какие цели преследует и кто инициатор. Это позволяет впоследствии легко вспомнить, зачем это было сделано, кому это было нужно и сохраняется ли такая необходимость сейчас. Даже если изменение чисто техническое, также укажите это, чтобы потом не вспоминать для чего именно был установлен этот патч или сделана эта настройка.

Описание зависимостей.

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

Выделение ресурсов.

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

Подготовка.

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

Планирование.

Самый важный пункт документации. Он должен как можно более подробно и последовательно описывать все действия по внесению изменений. Сначала укажите более общие этапы, затем перейдите к более частным. Обычно на этом этапе всплывает 90% подводных камней, когда выясняется, что еще нужно сделать это и это, а также чуть не забыли это. В итоге из "полчаса делов и одна перезагрузка" изменение превращается во вдумчивую работу на пару часов. Подробно укажите действия на каждом этапе и планируемый результат данных действий.

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

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

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

План восстановления.

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

Наличие плана восстановления хорошо тем, что в аварийная ситуация не перерастет в авральную, а будет находиться под контролем. Не забудьте четко ограничить временные рамки, по истечению которых вам нужно переходить к восстановлению. Например у вас есть 2 часа, планируемое время изменений - 20 минут, планируемое время восстановления - 40 минут. Следовательно на решение возможных проблем у вас есть час. Т.е. при наступлении времени Ч + 1 ч 20 мин вам следует прекратить все попытки и приступить к восстановлению.

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

Заключение.

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

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

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

Также наличие детально проработанных планов, с отметками о выполнении, позволяет избежать конфликтных ситуаций с руководством, которое, не видя немедленного результата от проводимых администратором действий, может считать, что вы ничего не делаете или уделяете вопросу недостаточно времени.

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

Записки IT специалиста