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