Не так давно, в городе N одна IT-компания, специализирующаяся на работе с данными клиентов, успешно вела свою работу в своём ДЦ в режиме 24/7. Тот самый случай, когда «сапожник в сапогах», т.е. в IT-компании IT было хорошо отлажено. Интересное началось, когда после многих лет работы свой пост покинул технический директор, который стоял у основ, на котором держался контроль за исправной работой всей IT-вертикали. На смену пришел человек не менее опытный (далее по тексту – “профи”), и даже с более широким кругозором, он буквально очаровал “бизнес” новыми горизонтами развития. Но, как это часто бывает, люди высокого полёта очень неохотно спускаются на землю уровень рядового администрирования.
Хронометраж инцидента:
День первый (апрель): одна местная СХД начала сыпать alert-ами, а потом среди них появились и первые error-ы. Увидев это, админ известил своего руководителя согласно инструкции. Наш профи отмахнулся отпиской ответным письмом, следуя “золотому правилу программиста” – “Работает? Не трогай!”.
Отступление первого дня — Обычно СХД общается с помощью оповещений среди которых стоит выделить Алерты (от “Alert”) – сигналы тревоги. По сути, это оповещения, сигнализирующие о тревожном событии или предупреждающие его. Типы оповещений:
Варнинги (от “Warning”) – предупреждения; как правило дают время спокойно подумать.
Эрроры (от “Error”) – ошибки; например, вылетел диск, но доступ к данным не прервался; здесь уже не стоит откладывать их решение на потом.
Критикал эрроры (от “Critical Error”) – критические ошибки, гарантированно произошло нарушение работы, решение требуется незамедлительно.
На этапе разработки(доработки/изменения) архитектуры, появляется (а впоследствии дополняется/изменяется) таблица по образу плана аварийного восстановления, начиная с самых экстремальных сценариев и заканчивая самыми легкими. Пример заготовки такого плана (важно составлять свой и поддерживать актуальность именно для своей системы) ниже, полную таблицу с примером плана аварийного восстановления можно скачать по ссылке
День второй (июнь): наш инженер (Агат-А), работая по другому проекту заказчика, узнает об этих ошибках, и интересуется “а что предприняли-то?”, ответ – “ничего, кейс у себя во внутренней системе завели, руководство в курсе, …”. Со стороны местного админа всё было сделано по стандартному процессу, четко по инструкции ещё два месяца назад. На вопрос — может нужно помочь, админ ответил, что свою часть выполнил, а команд никаких не было.
Отступление второго дня:
Введение и разумное использование чек-листа аварийного восстановления работоспособности поможет восстановить общую картину действий, а также может помочь избежать очевидных ошибок и излишней суеты.
Пример чек-листа аварийного восстановления работоспособности комплекса:
Все действия и события во время аварийного восстановления работоспособности обязательно фиксируется с указанием времени, ответственного и результатами работ на каждом этапе.
Ведение журнала — обязанность руководителя команды аварийного восстановления работоспособности. Данный журнал должен начинаться с самого начала — с момента оповещения об аварии.
Копия данного журнала направляется к директору департамента, ответственного за работу данного предприятия, как только первая опасность будет устранена.
Нижеследующий журнал заполняется руководителем команды аварийного восстановления для записи всех ключевых событий во время аварийного восстановления до тех пор, пока ответственность не будет передана руководителю восстановления работы бизнеса — директору департамента.
День третий (июль): игнорирование ошибок привело к тому, что СХД стала менее отзывчивой и уже “почему-то” не всегда тянула навалившиеся задачи, появились первые жалобы клиентов на скорость работы в часы пик. И вот тут уже с профи (ИТ-руководителя) спросили на планерке. Он понял, что пора что-то делать и спустился в «машинное отделение». Итог – в течение дня на портале вендора был открыт кейс по поводу … отказавшего контроллера!
После этого инженер заказчика вежливо попросил нас помочь. Отдельно необходимо упомянуть, что в целях экономии при покупке системы партнерскую и вендорскую поддержку onsite «порезали» и де-юре мы вообще не должны были этими вопросами заниматься, но, в счет наличия хороших отношений с заказчиком и реализуемых примерно раз в полтора года проектов, мы подключились к решению проблемы по просьбе заказчика. Сразу просим снять логи, оперативно их получаем, более четко описываем ситуацию для обращения в поддержку вендора, выставляем важность и т.д. По логам видно, что один контроллер умер, а второй сбоит, но ошибки исправляет на лету, причем батарейка во втором контроллере уже тоже сдохла. Объявляем диагноз (хорошо, что не приговор), ускоряем заказ контроллеров у производителя, как водится, их не оказалось на российском складе.
Отступление третьего дня — прорабатывая варианты отказов и методы их решения, важно начинать с самых дорогих. Можно в виде очень простой таблички по образу Плана восстановления выше. Также полезно создать и поддерживать в актуальном состоянии план внедрения/развёртывания комплекса с нуля.
А для поддержания надежности комплекса стоит составить и исполнять плановые проверки.
Например:
Необходимо проверять работоспособность резервного генератора каждый первый рабочий вторник месяца.
Ответственный: дежурный электрик ____________________.
Контролирующий: ____________________.
Необходимо производить проверку последней резервной копии один раз в неделю на полноту и консистентность данных.
Ответственный: ведущий инженер ____________________.
Руководитель: ____________________.
Можно составить списки критически важных сервисов, чтобы начинать восстановление с них.
Для того, чтобы вовремя узнавать о сбоях необходимо настроить систему оповещений и проверять её работу также по расписанию с ответственными.
Важно распределять роли и обязанности между сотрудниками, чтобы каждый знал, к кому обращаться в чрезвычайной ситуации, а также их заместителей. Важно указывать реальных людей с реальными контактами, а не просто роли.
Тестирования отказоустойчивости и катастрофоустойчивости могут проходить в различных форматах:
День четвертый (август): спустя несколько недель контроллеры преодолели таможню и добрались до серверной заказчика (попутно мы переписали серийники, они понадобятся для закрытия кейса в поддержке вендора при отправке старых контроллеров). Путь с таможни до серверной – 2 дня. А дальше … снова началась неторопливая действительность. И зачем мы так торопились? От предложенной замены контроллеров нашими спецами или хотя бы сопровождения данного процесса, заказчик отказался, чай мы и сами не дураки, разберемся (как показала практика во время работы предыдущего технического директора это было 100-% правдой). По условиям сервиса нужно (очень желательно!) отправить замененные старые контроллеры обратно производителю в течение двух недель. Производитель напоминал заказчику о возврате неоднократно.
Отступление четвертого дня — люди будьте человеками, не бойтесь задать вопрос, не стесняйтесь попросить помощи и не брезгуйте перепроверить самих себя. Конечно, есть люди, которые могут на своём горбу, опыте и способности работать по 12 часов в день, тащить всю организационную составляющую. Работа в команде подразумевает, что каждый использует свои сильные стороны, а не наоборот. Как специалисты, прорабатывайте резервные варианты до наступления критических ситуаций. Готовьтесь к ним заранее и пусть они обойдут вас стороной. А если даже что-либо случится, вы уже будете готовы и сможете пройти эти испытания с минимальными потерями.
День пятый (октябрь, Кульминация):
Далее следует текст, написанный нашим инженером от первого лица.
Рано утром, когда до офиса оставалось минут 5 пешком, приходит звонок с неизвестного номера. Отвечаю на вызов – встревоженный голос просит помочь их профи решить проблему с их СХД, т.к. клиенты не могут получить доступ к их сервису. По ходу разговора пытаюсь идентифицировать заказчика. А, точно они, припоминаю, что он (профи) вроде уже устранил SPoF (единую точку отказа) в виде полностью нерабочего контроллера, но постоянно откладывал замену второго, сбоящего. Ладно, больше технических подробностей скажет только технарь, потому согласовываем и сразу осуществляем созвон с профи и админом, кстати абсолютно новым админом, которого оказывается взяли на работу в начале сентября.
Начинаю задавать вопросы, много всё более точечных вопросов, стараясь локализовать проблему. Цитирую некоторые ответы в связки новый админ + профи: «старый мёртвый контроллер замен почти сразу, в конце августа или начале сентября” … “второй так и не поменяли, хотели вместе с его заменой ещё и какие-то работы сделать, требующие выключения системы” … “до сих пор все работало” … “ерроров и критикал ерроров уже не было” … “и тут СХД заглохла” … “из сети не достучаться” … “все сервисы упали” … “часть лампочек не горит” … “не мигает где обычно мигало” … “я не понимаю, что это значит».
Спустя несколько минут, благодаря ответам на мои вопросы появилась картина, но тут произошло первое накрытие. На очередной вопрос: а сохранилась ли резервная копия настроек контроллера, я вдруг услышал полное молчание. Спустя минуту картина дополнилась: Профи заменил (физически вынул старый и вставил на его место новый, цитирую: критикал еррор пропал) один контроллер (тот, что был полностью мертвый) не выключая СХД. И собственно, всё! Он после этого больше ничего с ним не сделал, НИЧЕГО!!! “Лампочка же загорелась, критикал эррор пропал.” Замену второго (еле живого контроллера) он оставил до выключения СХД, которое откладывалось почти полтора месяца (снова второе правило в действии). Тут уже я попросил паузу на подумать (на самом деле переварить, т.к. мозг просто отказывался верить в услышанное).
Немного очухавшись (наверное, минута тишины), наконец осознаю: один сдох, его заменили пустым новым, второй дожил свой век (более трех месяцев бедолага в одиночку тянул со сдохшей батарейкой и со сразу исправляемыми одиночными ошибками всю их систему) и тоже сдох. Копии настроек нет, где взять сами настройки люди сходу ответить не могут, удаленку дать не могут физически (“что-то” с интернетом), а человеко-часы теряются.
Сначала прикинул как это можно исправить, дальше начал уточнять про сеть, можно ли оперативно получить карту сети (нет нельзя, под рукой почти ничего нет). Спустя пару минут безответного стука в разные ворота к разным сервисам, СХД и сетевому оборудованию (я спрашивал и говорил, что сделать, мне отвечали, что вышло, всё происходит без удаленки, т.к. “интернета тоже почему-то нет”. Из вопрос-ответов до меня доходит, что dhcp сервера виртуальные и они запускаются именно с этой СХД, статики считай нигде нет и поэтому ВСЁ недоступно. Это было второе накрытие (только я подумал, что ниже спуститься уже некуда, как снизу постучались: порты управления без статики — это зло). Ладно, в этот раз я очухался гораздо быстрее, нарисовал в голове примерный план действий и объяснил его “коллегам”: что нужен компьютер или ноут с патч-кордом рядом с СХД и руки рядом. Дальше нужны: инструкция по настройке контроллера (если отсутствует/потеряли, то сейчас же найду и вышлю) и “кусок” карты сети вокруг СХД (“кусок” = основные сетевые настройки). Когда всё это было готово базово настраиваем новые контроллеры СХД, подключаясь к ним напрямую с нашего ноута с патч-кордом по инструкции, используя найденные сетевые настройки, поднимаем ваш DHCP и настраиваем контроллеры СХД уже по-боевому, поднимая каждую систему и проверяя, что она работает как нужно. Нахожу и высылаю инструкцию (кстати корпоративная почта также не работает, т.к. она тоже зависит от этой СХД, потому использую личную почту…), плюс к этому времени профи нашел хотя бы базовые сетевые настройки для СХД (ip адреса обоих контролеров и т.п.). У профи наконец появилось понимание что делать, и он сказал, что дальше справится сам. Я напомнил, что на связи и отпустил. Спустя некоторое время сервис “24/7” у этого клиента заработал.
Для меня весь инцидент уместился в четыре десятка минут, и с одной стороны мне было приятно, что получилось решить задачу оперативно в режиме онлайн и по телефону, с другой стороны мне было очень удивительно, как можно дойти до жизни такой. И клиенты этой айти компании тоже не оценили данный инцидент, т.к. сервис по обещаниям должен был работать 24/7 и это было начало рабочего дня (а с учетом часовых поясов у кого-то был даже разгар рабочего дня).
На этом мог бы быть конец, но для меня завершение кейса – это работа над ошибками. Потому мы с коллегами попробовали написать: что можно/нужно изменить в нашей (и не только нашей) работе, чтобы не допускать подобного в будущем.
Данный кейс оказался просто бесплатной работой, нам даже спасибо не буркнули. Понятно, т.к. мы увидели то, что заказчику хотелось бы поскорее забыть, а свидетелей закопать в лесу. Но этот кейс пополнил нашу коллекцию шпаргалок/шаблонов для самых частых ситуаций, с которыми сталкиваются администраторы, инженеры и бизнес, при использовании и обслуживании СХД и смежных с ними систем. Хотя для кого-то, эти шпаргалки и инструкции могут показаться слишком простыми или даже узкими. В любом случае для каждой системы нужно вписывать свои данные в эти шпаргалки/шаблоны (ведь у всех свой ландшафт, свои требования к информации и сервисам и т.д.), рисовать свои схемы, вырабатывать свои алгоритмы.
Напоследок приведем пример политики резервного копирования.
Подобная шпаргалка, созданная для своей системы, может сильно помочь как новичку, так и мастеру. Даже если мастер может удержать всё в голове, он не биоробот с графиком работы 24/7. И в любом случае любой инструмент требует разумного его использования.
И напевая «А тем кто ложится спать, спокойного сна» заканчиваем наше повествование.
Хронометраж инцидента:
День первый (апрель): одна местная СХД начала сыпать alert-ами, а потом среди них появились и первые error-ы. Увидев это, админ известил своего руководителя согласно инструкции. Наш профи отмахнулся отпиской ответным письмом, следуя “золотому правилу программиста” – “Работает? Не трогай!”.
Отступление первого дня — Обычно СХД общается с помощью оповещений среди которых стоит выделить Алерты (от “Alert”) – сигналы тревоги. По сути, это оповещения, сигнализирующие о тревожном событии или предупреждающие его. Типы оповещений:
Варнинги (от “Warning”) – предупреждения; как правило дают время спокойно подумать.
Эрроры (от “Error”) – ошибки; например, вылетел диск, но доступ к данным не прервался; здесь уже не стоит откладывать их решение на потом.
Критикал эрроры (от “Critical Error”) – критические ошибки, гарантированно произошло нарушение работы, решение требуется незамедлительно.
На этапе разработки(доработки/изменения) архитектуры, появляется (а впоследствии дополняется/изменяется) таблица по образу плана аварийного восстановления, начиная с самых экстремальных сценариев и заканчивая самыми легкими. Пример заготовки такого плана (важно составлять свой и поддерживать актуальность именно для своей системы) ниже, полную таблицу с примером плана аварийного восстановления можно скачать по ссылке
День второй (июнь): наш инженер (Агат-А), работая по другому проекту заказчика, узнает об этих ошибках, и интересуется “а что предприняли-то?”, ответ – “ничего, кейс у себя во внутренней системе завели, руководство в курсе, …”. Со стороны местного админа всё было сделано по стандартному процессу, четко по инструкции ещё два месяца назад. На вопрос — может нужно помочь, админ ответил, что свою часть выполнил, а команд никаких не было.
Отступление второго дня:
Введение и разумное использование чек-листа аварийного восстановления работоспособности поможет восстановить общую картину действий, а также может помочь избежать очевидных ошибок и излишней суеты.
Пример чек-листа аварийного восстановления работоспособности комплекса:
Все действия и события во время аварийного восстановления работоспособности обязательно фиксируется с указанием времени, ответственного и результатами работ на каждом этапе.
Ведение журнала — обязанность руководителя команды аварийного восстановления работоспособности. Данный журнал должен начинаться с самого начала — с момента оповещения об аварии.
Копия данного журнала направляется к директору департамента, ответственного за работу данного предприятия, как только первая опасность будет устранена.
Нижеследующий журнал заполняется руководителем команды аварийного восстановления для записи всех ключевых событий во время аварийного восстановления до тех пор, пока ответственность не будет передана руководителю восстановления работы бизнеса — директору департамента.
День третий (июль): игнорирование ошибок привело к тому, что СХД стала менее отзывчивой и уже “почему-то” не всегда тянула навалившиеся задачи, появились первые жалобы клиентов на скорость работы в часы пик. И вот тут уже с профи (ИТ-руководителя) спросили на планерке. Он понял, что пора что-то делать и спустился в «машинное отделение». Итог – в течение дня на портале вендора был открыт кейс по поводу … отказавшего контроллера!
После этого инженер заказчика вежливо попросил нас помочь. Отдельно необходимо упомянуть, что в целях экономии при покупке системы партнерскую и вендорскую поддержку onsite «порезали» и де-юре мы вообще не должны были этими вопросами заниматься, но, в счет наличия хороших отношений с заказчиком и реализуемых примерно раз в полтора года проектов, мы подключились к решению проблемы по просьбе заказчика. Сразу просим снять логи, оперативно их получаем, более четко описываем ситуацию для обращения в поддержку вендора, выставляем важность и т.д. По логам видно, что один контроллер умер, а второй сбоит, но ошибки исправляет на лету, причем батарейка во втором контроллере уже тоже сдохла. Объявляем диагноз (хорошо, что не приговор), ускоряем заказ контроллеров у производителя, как водится, их не оказалось на российском складе.
Отступление третьего дня — прорабатывая варианты отказов и методы их решения, важно начинать с самых дорогих. Можно в виде очень простой таблички по образу Плана восстановления выше. Также полезно создать и поддерживать в актуальном состоянии план внедрения/развёртывания комплекса с нуля.
А для поддержания надежности комплекса стоит составить и исполнять плановые проверки.
Например:
Необходимо проверять работоспособность резервного генератора каждый первый рабочий вторник месяца.
Ответственный: дежурный электрик ____________________.
Контролирующий: ____________________.
Необходимо производить проверку последней резервной копии один раз в неделю на полноту и консистентность данных.
Ответственный: ведущий инженер ____________________.
Руководитель: ____________________.
Можно составить списки критически важных сервисов, чтобы начинать восстановление с них.
Для того, чтобы вовремя узнавать о сбоях необходимо настроить систему оповещений и проверять её работу также по расписанию с ответственными.
Важно распределять роли и обязанности между сотрудниками, чтобы каждый знал, к кому обращаться в чрезвычайной ситуации, а также их заместителей. Важно указывать реальных людей с реальными контактами, а не просто роли.
Тестирования отказоустойчивости и катастрофоустойчивости могут проходить в различных форматах:
- Проработка действий с командой, т.е. сотрудники устно проходят пункты, указанные в плане, выявляют пробелы и трудные места.
- Моделирование аварийного сбоя, т.е. производится имитация инцидента без прерывания работы основной IT-инфраструктуры.
- Тестирование в рабочем режиме.
- Полное прохождение действий плана аварийного восстановления с необходимым отключением основной IT-инфраструктуры.
День четвертый (август): спустя несколько недель контроллеры преодолели таможню и добрались до серверной заказчика (попутно мы переписали серийники, они понадобятся для закрытия кейса в поддержке вендора при отправке старых контроллеров). Путь с таможни до серверной – 2 дня. А дальше … снова началась неторопливая действительность. И зачем мы так торопились? От предложенной замены контроллеров нашими спецами или хотя бы сопровождения данного процесса, заказчик отказался, чай мы и сами не дураки, разберемся (как показала практика во время работы предыдущего технического директора это было 100-% правдой). По условиям сервиса нужно (очень желательно!) отправить замененные старые контроллеры обратно производителю в течение двух недель. Производитель напоминал заказчику о возврате неоднократно.
Отступление четвертого дня — люди будьте человеками, не бойтесь задать вопрос, не стесняйтесь попросить помощи и не брезгуйте перепроверить самих себя. Конечно, есть люди, которые могут на своём горбу, опыте и способности работать по 12 часов в день, тащить всю организационную составляющую. Работа в команде подразумевает, что каждый использует свои сильные стороны, а не наоборот. Как специалисты, прорабатывайте резервные варианты до наступления критических ситуаций. Готовьтесь к ним заранее и пусть они обойдут вас стороной. А если даже что-либо случится, вы уже будете готовы и сможете пройти эти испытания с минимальными потерями.
День пятый (октябрь, Кульминация):
Далее следует текст, написанный нашим инженером от первого лица.
Рано утром, когда до офиса оставалось минут 5 пешком, приходит звонок с неизвестного номера. Отвечаю на вызов – встревоженный голос просит помочь их профи решить проблему с их СХД, т.к. клиенты не могут получить доступ к их сервису. По ходу разговора пытаюсь идентифицировать заказчика. А, точно они, припоминаю, что он (профи) вроде уже устранил SPoF (единую точку отказа) в виде полностью нерабочего контроллера, но постоянно откладывал замену второго, сбоящего. Ладно, больше технических подробностей скажет только технарь, потому согласовываем и сразу осуществляем созвон с профи и админом, кстати абсолютно новым админом, которого оказывается взяли на работу в начале сентября.
Начинаю задавать вопросы, много всё более точечных вопросов, стараясь локализовать проблему. Цитирую некоторые ответы в связки новый админ + профи: «старый мёртвый контроллер замен почти сразу, в конце августа или начале сентября” … “второй так и не поменяли, хотели вместе с его заменой ещё и какие-то работы сделать, требующие выключения системы” … “до сих пор все работало” … “ерроров и критикал ерроров уже не было” … “и тут СХД заглохла” … “из сети не достучаться” … “все сервисы упали” … “часть лампочек не горит” … “не мигает где обычно мигало” … “я не понимаю, что это значит».
Спустя несколько минут, благодаря ответам на мои вопросы появилась картина, но тут произошло первое накрытие. На очередной вопрос: а сохранилась ли резервная копия настроек контроллера, я вдруг услышал полное молчание. Спустя минуту картина дополнилась: Профи заменил (физически вынул старый и вставил на его место новый, цитирую: критикал еррор пропал) один контроллер (тот, что был полностью мертвый) не выключая СХД. И собственно, всё! Он после этого больше ничего с ним не сделал, НИЧЕГО!!! “Лампочка же загорелась, критикал эррор пропал.” Замену второго (еле живого контроллера) он оставил до выключения СХД, которое откладывалось почти полтора месяца (снова второе правило в действии). Тут уже я попросил паузу на подумать (на самом деле переварить, т.к. мозг просто отказывался верить в услышанное).
Немного очухавшись (наверное, минута тишины), наконец осознаю: один сдох, его заменили пустым новым, второй дожил свой век (более трех месяцев бедолага в одиночку тянул со сдохшей батарейкой и со сразу исправляемыми одиночными ошибками всю их систему) и тоже сдох. Копии настроек нет, где взять сами настройки люди сходу ответить не могут, удаленку дать не могут физически (“что-то” с интернетом), а человеко-часы теряются.
Сначала прикинул как это можно исправить, дальше начал уточнять про сеть, можно ли оперативно получить карту сети (нет нельзя, под рукой почти ничего нет). Спустя пару минут безответного стука в разные ворота к разным сервисам, СХД и сетевому оборудованию (я спрашивал и говорил, что сделать, мне отвечали, что вышло, всё происходит без удаленки, т.к. “интернета тоже почему-то нет”. Из вопрос-ответов до меня доходит, что dhcp сервера виртуальные и они запускаются именно с этой СХД, статики считай нигде нет и поэтому ВСЁ недоступно. Это было второе накрытие (только я подумал, что ниже спуститься уже некуда, как снизу постучались: порты управления без статики — это зло). Ладно, в этот раз я очухался гораздо быстрее, нарисовал в голове примерный план действий и объяснил его “коллегам”: что нужен компьютер или ноут с патч-кордом рядом с СХД и руки рядом. Дальше нужны: инструкция по настройке контроллера (если отсутствует/потеряли, то сейчас же найду и вышлю) и “кусок” карты сети вокруг СХД (“кусок” = основные сетевые настройки). Когда всё это было готово базово настраиваем новые контроллеры СХД, подключаясь к ним напрямую с нашего ноута с патч-кордом по инструкции, используя найденные сетевые настройки, поднимаем ваш DHCP и настраиваем контроллеры СХД уже по-боевому, поднимая каждую систему и проверяя, что она работает как нужно. Нахожу и высылаю инструкцию (кстати корпоративная почта также не работает, т.к. она тоже зависит от этой СХД, потому использую личную почту…), плюс к этому времени профи нашел хотя бы базовые сетевые настройки для СХД (ip адреса обоих контролеров и т.п.). У профи наконец появилось понимание что делать, и он сказал, что дальше справится сам. Я напомнил, что на связи и отпустил. Спустя некоторое время сервис “24/7” у этого клиента заработал.
Для меня весь инцидент уместился в четыре десятка минут, и с одной стороны мне было приятно, что получилось решить задачу оперативно в режиме онлайн и по телефону, с другой стороны мне было очень удивительно, как можно дойти до жизни такой. И клиенты этой айти компании тоже не оценили данный инцидент, т.к. сервис по обещаниям должен был работать 24/7 и это было начало рабочего дня (а с учетом часовых поясов у кого-то был даже разгар рабочего дня).
На этом мог бы быть конец, но для меня завершение кейса – это работа над ошибками. Потому мы с коллегами попробовали написать: что можно/нужно изменить в нашей (и не только нашей) работе, чтобы не допускать подобного в будущем.
Данный кейс оказался просто бесплатной работой, нам даже спасибо не буркнули. Понятно, т.к. мы увидели то, что заказчику хотелось бы поскорее забыть, а свидетелей закопать в лесу. Но этот кейс пополнил нашу коллекцию шпаргалок/шаблонов для самых частых ситуаций, с которыми сталкиваются администраторы, инженеры и бизнес, при использовании и обслуживании СХД и смежных с ними систем. Хотя для кого-то, эти шпаргалки и инструкции могут показаться слишком простыми или даже узкими. В любом случае для каждой системы нужно вписывать свои данные в эти шпаргалки/шаблоны (ведь у всех свой ландшафт, свои требования к информации и сервисам и т.д.), рисовать свои схемы, вырабатывать свои алгоритмы.
Напоследок приведем пример политики резервного копирования.
Подобная шпаргалка, созданная для своей системы, может сильно помочь как новичку, так и мастеру. Даже если мастер может удержать всё в голове, он не биоробот с графиком работы 24/7. И в любом случае любой инструмент требует разумного его использования.
И напевая «А тем кто ложится спать, спокойного сна» заканчиваем наше повествование.