Сбои - это некоторые из вещей, которых мы стараемся избегать, но они неизбежны: они случаются (мы надеемся, что очень редко), и мы должны знать, как с ними бороться (и учиться на них).
Итак, в чем именно вы участвовали? Как вы и ваша команда справились с проблемой? Что вы узнали на будущее? Пожалуйста, поделитесь своими мыслями :)
У нас был паропровод греющего пара, который проходил через разрыв нашего центра обработки данных. Очень горячая, конденсационная и асбестовая изоляция повсюду. Отключение электричества на несколько недель во время очистки.
в порядке, мой Группа работала по протоколу BGP с балансировкой нагрузки между несколькими центрами обработки данных. У нас была некоторая часть наших пользователей, которая зависала на 30 секунд перед переносом их текущей транзакции. Во многих других проектах были отключены до нескольких дней, и каждый вкладывал много сверхурочных, чтобы помочь всем остальным.
Извлеченные уроки: сначала спланируйте непрерывность, а затем создайте систему, подтверждающую ваши выводы:
Я «участвую» в отключениях почти каждый день (отслеживайте ссылки WAN для 44 сайтов). «Малыши» - это те, которые работают менее 5 минут и большую часть времени остаются «незамеченными» (по какой-то причине NOC отслеживает только отключения, превышающие 5 минут). Я пытаюсь связаться с сайтом, чтобы узнать, не было ли это внутренней проблемой, и проверяю журналы маршрутизатора всякий раз, когда проблема «неизвестна».
я нахожу Общение является ключевым (и это еще не все!) при работе с простоями. НЕ ДОЛЖНЫ СВЯЗАТЬСЯ с вами, пока вы устраняете неполадки или пытаетесь выяснить, что именно произошло. Убедитесь, что вы знаете, что они не работают, и что вы работаете над этим. Дайте им временные рамки, когда вы вернетесь к ним, чтобы сообщить им обновленную информацию о ситуации (ETR). Не позволяйте им думать, что вы забыли о них, убедитесь, что они ЗНАЮТ, что кто-то смотрит на их проблему. Вы звоните им, чтобы они не звонили вам.
К счастью, дольше всего сайт не работал под моим контролем - 7 часов (это рабочий день с 10 до 17 часов). Он должен был быть короче на несколько часов, если бы не отсутствие хорошей связи между всеми вовлеченными сторонами. В значительной степени проблема не была обострена должным образом, и из-за предположения, что «кто-то над этим работал», проблема потребовала (относительно сайта) навсегда, чтобы решить ее.
Я был на собеседовании в компании, которая в настоящее время столкнулась с отключением всей сети в своем офисе с более чем 50 пользователями. Я решил ее за считанные минуты и встретился с их текущим системным администратором и их компанией по поддержке ИТ, в которую они позвонили, потому что он не смог ее решить - они потратили все утро, пытаясь понять, в чем дело.
Предыдущий парень установил два беспроводных маршрутизатора в режиме моста и подключил их к проводной сети. Они едва находились в пределах досягаемости друг друга, поэтому в их сети образовалась петля, которая приходила и уходила при изменении приема.
Излишне говорить, что я получил работу и, как только начал, внедрил ведение журнала управления изменениями.
Я испытал недельный сбой всей нашей серверной сети. Мы справились с этим, создав сеть резервирования, чтобы предотвратить ту же самую проблему в будущем, но пока происходил сбой, мы использовали старый сервер, который мы установили в удаленном месте. Мы научились всегда иметь запасной план.
Вероятно, самой большой из них был 4-дневный сбой в работе всей штаб-квартиры, вызванный серьезным обновлением сети.
Самый большой совет, который у меня есть, - иметь налаженный надежный процесс управления инцидентами. На конференции Velocity 2008, которую я видел, есть блестящая презентация об адаптации общей системы управления инцидентами, используемой аварийным персоналом (http://en.wikipedia.org/wiki/Incident_Command_System) к инцидентам IT-типа: http://en.oreilly.com/velocity2008/public/schedule/detail/1525
Мы много заимствовали из этого при разработке собственного внутреннего процесса инцидента «Sev1». Он подчеркивает важность коммуникации, единоначалия, четкой передачи ответственности и других важных вещей.
Я также добавлю плагин для блога Transparent Uptime: http://www.transparentuptime.com/ - это онлайн-сервис, но его общие правила о том, как / что сообщать в случае сбоя, распространяются и на внутренние ИТ-службы. http://www.transparentuptime.com/2010/03/guideline-for-postmortem-communication.html в частности - у нас была менеджерская кроватка, и мы начали рассылать сообщения в таком формате, и вы не поверите, что положительный ответ.
Как вовремя. Я только что вернулся из экстренной поездки на один из поддерживаемых нами сайтов.
Что касается воздействия на пользователя, то это не было серьезным воздействием, но оно могло быть. В рамках текущего проекта по переносу некоторых сайтов с нашей поддержки мы создали новый доверенный домен. После тщательного тестирования мы подготовились к миграции первого сайта на новый домен, которым мы все еще будем управлять. Наступает ночь миграции, и мы начинаем с миграции одного из двух контроллеров домена в новый домен. Все идет нормально. Мы переносим группы безопасности и учетные записи пользователей. Это тоже нормально, и членство в группах обновляется должным образом. Мы переносим файловый сервер и выполняем перевод безопасности для обновления списков контроля доступа. Опять все идет хорошо. Перенесите серверы приложений и обновите IAS для VPN и никаких проблем. Затем мы переносим тестовый пользовательский ПК, и пользователь сохраняет настройки своего профиля и может получить полный доступ ко всем сетевым ресурсам. Затем мы переносим другой DC. Затем мы переносим оставшиеся компьютеры, и половина из них терпит неудачу. Мы обнаруживаем, что локальный брандмауэр XP включен. Я немедленно отправляю объект групповой политики на сайт, чтобы выключить его, но мне придется дождаться обновления компьютеров. Это происходит недостаточно быстро, и пользователи начинают приходить. Они не могут войти в исходный домен, потому что оба контроллера домена находятся в новом.
Вместо этого попробуйте повторно добавить один контроллер домена обратно в исходный домен. Мы обновляем правила брандмауэра, чтобы разрешить доступ другим удаленным контроллерам домена для исходного домена, и проехать 3 часа до сайта.
Немного спит: объект групповой политики для отключения локального брандмауэра отключен. Не задумываясь, я беру все компьютерные объекты и запускаю миграцию. Я забыл, что это СБРОСИТ объекты компьютера. Итак, теперь все успешно перенесенные ПК удалены из домена.
Что еще хуже, пропуск локального администратора, который мы запускаем с нашим изображением, не работает из-за давно ушедшей технологии на месте, которая их сбрасывает.
Я потратил выходные вручную, добавляя все ПК в новый домен после использования загрузочного диска для очистки прохода локального администратора.
Уроки выучены:
Извините, что это было запоздало.