Что Cobit, что ITIL — это лучшие практики менеджмента, но в них, увы, содержаться лишь трактовки конечного результата, без инструкцию по их достижению.
Ни в коем случае не принижаю ценности и значения этих документов, однако помимо общих терминов в реальной жизни ты сталкиваешься еще и необходимостью разработки методологии по тому как составить ИТ-бюджет, провести анализ рисков, спланировать аварийное восстановление, или же сделать аудит ИТ-инфраструктуры или ИТ-отдела. Т.е. ты всегда стоишь перед вопросом как из состояния где ты находишься сейчас перейти в состояние по ITIL или хотя бы к его подобию. Собственно, эти процессы я и описываю в своих статьях.
Вообще стандарт Cobit — это нечто непонятное за семью печатями и в общем случае недоступное обычному обывателю. Такой священный Грааль. Вы сами то его читали?
К сожалению, есть целые области, где такие компании становятся единственным и последним этапом в эволюции системного администратора. И в этом нет ничего плохого, если специалист получает за свою работу достойную компенсацию и может организовать свой труд.
Должен вас разочаровать — есть компании, где кроме сисадмина нет больше ни одного технического специалиста в штате и это еще вопрос, где ИТ-специалистов работает больше — в мелких бизнесах или в составе крупных ИТ-отделов.
Все дело в том, что в системном администрировании недостаточно быть просто хорошим технарем, необходимо быть еще и немного управленцем. Необходимо не только уметь настраивать те или иные железки, но и понимать основные принципы управления качеством, анализа рисков, выстраивания процессов обслуживания и управления ИТ-инфраструктурой, уметь проводить переговоры с руководством, определять и достигать цели совместно с бизнесом (как бы булшитно это не звучало).
Отсутствие управленческих навыков, неспособность договорится о формате работы и ее целях, трудности определения причин дискомфорта в работе и конструктивных методов их устранения, зачастую приводит к тому, что хорошие технические специалисты остаются один на один с грудой неразрешенных управленческих проблем, которые постоянно на них давят. Данные проблемы, как правило, менее заметны в крупных ИТ-отделах и принимает катастрофические размеры в небольших организациях.
Именно это и побудило меня писать статьи на хабре, связанные с вопросами менеджмента в системном администрировании, и именно поэтому я стараюсь писать их максимально доступным языком, чтобы они были понятны даже для начинающих сисадминов.
Все верно. Наличие необходимых компетенций и прямых рук — это одно из условий успеха аварийного восстановления. Планирование позволяет прямым рукам спокойно работать даже в случае аварии и не сталкиваться с «приятными» неожиданностями.
Когда написал черновик, было даже много для одной статьи. Затем я выкинул из него булшит, эмоции, «искрометный» юмор, лишние детали, а также то, что все и так знают. После этого выпарил оставшуюся воду, выкинув из статьи выводы, которые все сами могут сделать, и, в конечном итоге, оставил только саму соль. Перестарался?
Забыл самое главное — данная схема позволяет дополнительно проверить, что вы не пропустили никакую из точек отказа. А то так часто бывает, что приготовились ко всему, а какую-то маленькую деталь из планирования упустили и именно она и стала причиной сбоя. Так, например, регулярно из зоны планирования аварийного восстановления упускаются всякие аппаратные ключи лицензий, которые в компаниях в одном экземпляре и без которых, естественно, ничего не работает.
Именно поэтому я вынес этап анализа в отдельную статью, т.к. в процессе планирования аварийного восстановления по моему опыту этот этап самый важный.
Приведенная схема зависимости точек отказа помогает:
1) В формировании плана локализации, который сокращает временя на определение отказавшего элемента.
2) В определении влияния отказа того или иного элемента на бизнес, для последующего обоснования перед руководством необходимости его резервирования.
3) В определении необходимых и достаточных компетенции для устранения последствий аварий. К примеру, если у нас упал гипервизор, то мы будем посреди ночи не только специалистов по виртуализации, но еще и спецов по прикладным системам, чтобы те потом проверили и в случае необходимости восстановили зависимые точки отказа.
Ну а что касается «ускорения подъема почтового сервера», то для этого есть несколько критичных условий:
1) Доступность резервов для восстановления.
2) Доступность компетенций для оперативных работ.
3) Проработанность процедуры аварийного восстановления.
И еще пара моментов, о которых речь пойдет в следующей статье.
Если я правильно понял Ваш пример, он заключается в следующем: есть некоторая заложенная ошибка в ПО, которая при наступлении определенного события в будущем (прошествии периода времени, определенной даты («проблема тысячелетия») или выполнения ряда действий) приводит к необратимой потере данных, что даже восстановление из резервных копий не дает никаких результатов. Приводя данный пример, вы говорите, что все планы и «бюрократия» в этом случае идут лесом и надо просто дать время админу разобраться в случившемся, провести реверс-инженеринг программного обеспечения, найти ошибку в ПО и героически устранить ее.
Дак вот, плохая новость в том, что админ в таких ситуациях совершенно бесполезен. Точно также, как бесполезен офисный админ в вопросах «починки Интернета», когда проблемы в сети на M9, даже если в офиса 3 канала «Интернет» от разных провайдеров. Хорошая в том, что от него не требуется в таких ситуациях применять героизм и отвагу, а требуется обратиться к разработчикам/операторам связи и т.д. и привлечь их к решению данного вопроса. Планирование аварийного восстановления как раз и помогает заранее обозначить зоны ответственности и возможности по восстановлению, и согласовать их с руководством, чтобы в момент работы над аварией никто тебе не грозил «KPI». Этой темы я коснусь в третьей статье.
Также что касается заложенной ошибки в ПО я за свою практику знаю только об одном случае, когда это привело к потере данных — это отказ сверхнадежной и супердорогой СХД, когда через 3 дня разбора причин сбоя разработчики вендора признали, что допустили ошибку в коде, приводящую в определенных условиях к потере конфигурации СХД. Но этот сценарий проще, т.к. тут были регулярные ленточные бекапы и даже было хранилище попроще, куда все это можно было восстановить. Что касается ошибки в базе данных, которая приводит к невозможности восстановиться даже из корректно созданной резервной копии, то, на мой взгляд, в этом случае разработчики ПО будут кровно заинтересованы в том, чтобы устранить данный баг вне зависимости от наличия или отсутствия сервисного контракта, т.к. само по себе наличие возможности такой потери данных ставит крест на будущем данного продукта на рынке. Лично мне не известно ни одного случая приведенного вами сценария.
Вы отличаете бюрократию и планирование? Или по вашему мнению героизм и отвага позволят в любой ситуации добиться восстановления сервиса во вполне определенные временные рамки?
И да и нет. Если у вас для восстановления есть несколько дней, то можно вообще ничего не планировать и не заниматься «бюрократией с инцидентами», а положиться на то, что сисадмин «сделает все как надо». Но когда речь идет на часы, а то и на минуты и цель в том, чтобы это всегда были «часы» или «минуты», а не дни, без планирования не обойтись.
Есть вполне определенный и конечный набор того, что может сломаться. Задача планирования аварийного восстановления — знать, как восстановить, в какой момент принять решение о полном восстановлении и сколько в целом есть времени на исследование инцидента. То что спрашиваете вы, не входит в рамки аварийного восстановления — это уже вопрос управления Проблемами (поиска и устранения причин повторяющихся инцидентов).
Тем не менее, в рамках устранения Инцидентов если в ограниченные временные рамки не удается выявить точную причину сбоя, то сбойный элемент остается для дальнейшего исследование, а восстановление сервиса проводится с использованием других резервов. В дальнейшем сбойный элемент можно подвергнуть детальному исследованию.
Т.н. «самовосстановливающиеся системы» в рамках данных статей рассматриваются исключительно в качестве «точек отказа». Речь не о том, какие надежные системы существуют, речь о том, как подготовиться к ситуациям, когда даже надежные системы дают сбой.
Помогаю компаниям в вопросах организации надежной ИТ-службы: начиная от выстраивания процессов управления, составления бюджета на модернизацию ИТ-инфраструктуры и планирования аварийного восстановления, заканчивая подбором штатных специалистов и ИТ-директоров и предоставлением услуг аутсорсинга эксплуатации.
Была бы возможность — написал бы про все что можно, но время — ограниченный ресурс, так что приходится писать о том, что в первую очередь интересно самому. Возможно позже перейду и к практическим примерам, но в самых первых своих статьях хочу описать основные аспекты системного администрирования. По этой причине следующая статья будет о планировании аварийного восстановления, а не о практиках бюджетирования.
Я писал в предыдущих статьях, что по моей практике в первый год бизнес не понимает для чего им ИТ-бюджет, во второй год они смотрят на него с осторожностью, ну а на 3-4-ый год — ждут с нетерпением. Увы, сейчас такое время, когда не бизнес ставит требования к ИТ, а когда ИТ необходимо воспитывать бизнес — по этой причине я и пишу статьи на хабр.
Ни в коем случае не принижаю ценности и значения этих документов, однако помимо общих терминов в реальной жизни ты сталкиваешься еще и необходимостью разработки методологии по тому как составить ИТ-бюджет, провести анализ рисков, спланировать аварийное восстановление, или же сделать аудит ИТ-инфраструктуры или ИТ-отдела. Т.е. ты всегда стоишь перед вопросом как из состояния где ты находишься сейчас перейти в состояние по ITIL или хотя бы к его подобию. Собственно, эти процессы я и описываю в своих статьях.
Отсутствие управленческих навыков, неспособность договорится о формате работы и ее целях, трудности определения причин дискомфорта в работе и конструктивных методов их устранения, зачастую приводит к тому, что хорошие технические специалисты остаются один на один с грудой неразрешенных управленческих проблем, которые постоянно на них давят. Данные проблемы, как правило, менее заметны в крупных ИТ-отделах и принимает катастрофические размеры в небольших организациях.
Именно это и побудило меня писать статьи на хабре, связанные с вопросами менеджмента в системном администрировании, и именно поэтому я стараюсь писать их максимально доступным языком, чтобы они были понятны даже для начинающих сисадминов.
Именно поэтому я вынес этап анализа в отдельную статью, т.к. в процессе планирования аварийного восстановления по моему опыту этот этап самый важный.
1) В формировании плана локализации, который сокращает временя на определение отказавшего элемента.
2) В определении влияния отказа того или иного элемента на бизнес, для последующего обоснования перед руководством необходимости его резервирования.
3) В определении необходимых и достаточных компетенции для устранения последствий аварий. К примеру, если у нас упал гипервизор, то мы будем посреди ночи не только специалистов по виртуализации, но еще и спецов по прикладным системам, чтобы те потом проверили и в случае необходимости восстановили зависимые точки отказа.
Ну а что касается «ускорения подъема почтового сервера», то для этого есть несколько критичных условий:
1) Доступность резервов для восстановления.
2) Доступность компетенций для оперативных работ.
3) Проработанность процедуры аварийного восстановления.
И еще пара моментов, о которых речь пойдет в следующей статье.
Дак вот, плохая новость в том, что админ в таких ситуациях совершенно бесполезен. Точно также, как бесполезен офисный админ в вопросах «починки Интернета», когда проблемы в сети на M9, даже если в офиса 3 канала «Интернет» от разных провайдеров. Хорошая в том, что от него не требуется в таких ситуациях применять героизм и отвагу, а требуется обратиться к разработчикам/операторам связи и т.д. и привлечь их к решению данного вопроса. Планирование аварийного восстановления как раз и помогает заранее обозначить зоны ответственности и возможности по восстановлению, и согласовать их с руководством, чтобы в момент работы над аварией никто тебе не грозил «KPI». Этой темы я коснусь в третьей статье.
Также что касается заложенной ошибки в ПО я за свою практику знаю только об одном случае, когда это привело к потере данных — это отказ сверхнадежной и супердорогой СХД, когда через 3 дня разбора причин сбоя разработчики вендора признали, что допустили ошибку в коде, приводящую в определенных условиях к потере конфигурации СХД. Но этот сценарий проще, т.к. тут были регулярные ленточные бекапы и даже было хранилище попроще, куда все это можно было восстановить. Что касается ошибки в базе данных, которая приводит к невозможности восстановиться даже из корректно созданной резервной копии, то, на мой взгляд, в этом случае разработчики ПО будут кровно заинтересованы в том, чтобы устранить данный баг вне зависимости от наличия или отсутствия сервисного контракта, т.к. само по себе наличие возможности такой потери данных ставит крест на будущем данного продукта на рынке. Лично мне не известно ни одного случая приведенного вами сценария.
Тем не менее, в рамках устранения Инцидентов если в ограниченные временные рамки не удается выявить точную причину сбоя, то сбойный элемент остается для дальнейшего исследование, а восстановление сервиса проводится с использованием других резервов. В дальнейшем сбойный элемент можно подвергнуть детальному исследованию.
www.facebook.com/ivan.kormachev
www.depit.ru/