Comments 32
Схему руками рисовали или софт? По теме — спасибо, удобная методология.
Схема сделана руками в Visio.
Спасибо. Очень наглядно получилось. Я под такие задачи обычно Mindmap использую типа Xmind
ikormachev Спасибо! Сегодня при переводе описания доклада столкнулась с терминами: автономные компьютерные системы, самовосстановливающиеся / самоадаптивные системы. Собираетесь ли раскрыть и это направление?
Обожаю такие штуки. Всё ясно, просто и понятно.
Пока не приходит пушистый лесной зверь. Допустим, баг в софте, который возникает при условии наличия в почтовой базе письма с определённого размера вложения определённого типа с возрастом больше пяти дней. При наличии такого письма почтовый сервер перестаёт принимать нове письма и держит коннекты с входящими серверами на DATA, не отвечая ничего.
И как ваша схема позволит отладить эту проблему? То есть понятно, что «дело в софте», но где именно — «шут его знает». Для усиления драмы — после отката на бэкап недельной давности всё работает, но недельный откат никого не устраивает, а бэкапы за последующие 6 дней не поднимают сервер.
Я к тому, что в жизни оно обычно ломается не там, где подстелили соломки и укрепили, а совсем в неожиданных местах.
Пока не приходит пушистый лесной зверь. Допустим, баг в софте, который возникает при условии наличия в почтовой базе письма с определённого размера вложения определённого типа с возрастом больше пяти дней. При наличии такого письма почтовый сервер перестаёт принимать нове письма и держит коннекты с входящими серверами на DATA, не отвечая ничего.
И как ваша схема позволит отладить эту проблему? То есть понятно, что «дело в софте», но где именно — «шут его знает». Для усиления драмы — после отката на бэкап недельной давности всё работает, но недельный откат никого не устраивает, а бэкапы за последующие 6 дней не поднимают сервер.
Я к тому, что в жизни оно обычно ломается не там, где подстелили соломки и укрепили, а совсем в неожиданных местах.
Есть вполне определенный и конечный набор того, что может сломаться. Задача планирования аварийного восстановления — знать, как восстановить, в какой момент принять решение о полном восстановлении и сколько в целом есть времени на исследование инцидента. То что спрашиваете вы, не входит в рамки аварийного восстановления — это уже вопрос управления Проблемами (поиска и устранения причин повторяющихся инцидентов).
Тем не менее, в рамках устранения Инцидентов если в ограниченные временные рамки не удается выявить точную причину сбоя, то сбойный элемент остается для дальнейшего исследование, а восстановление сервиса проводится с использованием других резервов. В дальнейшем сбойный элемент можно подвергнуть детальному исследованию.
Тем не менее, в рамках устранения Инцидентов если в ограниченные временные рамки не удается выявить точную причину сбоя, то сбойный элемент остается для дальнейшего исследование, а восстановление сервиса проводится с использованием других резервов. В дальнейшем сбойный элемент можно подвергнуть детальному исследованию.
Я привёл простой и печальный пример, в котором надо выкинуть нафиг бюрократию с Инцедентами, Планами, Управлением, Перекладыванием-ответственности-на-кого-нибудь-другого и прочими попытками бюрократов управлять IT.
Этот печальный пример имеет два решения: либо контора теряет почту за неделю (при ежечасных бэкапах), либо кто-то саммонит сисадмина и тот применяет 'head' на 'installation', на выходе которого образуется решение проблемы, не описанное в схемах.
И по жизни именно так. Потому что попытка описать поведение тьюринг-полной системы требует больше, чем тьюринг-полная система (задача занятых бобров) и в общем случае не может быть решена.
Этот печальный пример имеет два решения: либо контора теряет почту за неделю (при ежечасных бэкапах), либо кто-то саммонит сисадмина и тот применяет 'head' на 'installation', на выходе которого образуется решение проблемы, не описанное в схемах.
И по жизни именно так. Потому что попытка описать поведение тьюринг-полной системы требует больше, чем тьюринг-полная система (задача занятых бобров) и в общем случае не может быть решена.
И да и нет. Если у вас для восстановления есть несколько дней, то можно вообще ничего не планировать и не заниматься «бюрократией с инцидентами», а положиться на то, что сисадмин «сделает все как надо». Но когда речь идет на часы, а то и на минуты и цель в том, чтобы это всегда были «часы» или «минуты», а не дни, без планирования не обойтись.
Ну, раз вы держитесь за бюрократию, даю установку:
бэкап раз в час, допустимые потери почты — не более полутора часов, предельный даунтайм — 4 часа.
Сервер упал. Все бэкапы младше недели (и текущая база) приводят к падению всех доступных версий сервиса. Восстановление из бэкапа занимает 30-40 минут.
Слово передаётся «планированию».
бэкап раз в час, допустимые потери почты — не более полутора часов, предельный даунтайм — 4 часа.
Сервер упал. Все бэкапы младше недели (и текущая база) приводят к падению всех доступных версий сервиса. Восстановление из бэкапа занимает 30-40 минут.
Слово передаётся «планированию».
Не все так быстро — ждите вторую часть.
Ну, достойный ответ бюрократии.
А я ещё раз повторю мысль, что никакая бюрократия:
а) не спасёт от field work
б) не позволит предсказать сколько это займёт
в) не поможет сократить умственную часть работы.
Всё, что может сделать бюрократия — это сократить время на бюрократию и неразбериху, пока человека не проинформируют о том, что work time.
А я ещё раз повторю мысль, что никакая бюрократия:
а) не спасёт от field work
б) не позволит предсказать сколько это займёт
в) не поможет сократить умственную часть работы.
Всё, что может сделать бюрократия — это сократить время на бюрократию и неразбериху, пока человека не проинформируют о том, что work time.
Вы отличаете бюрократию и планирование? Или по вашему мнению героизм и отвага позволят в любой ситуации добиться восстановления сервиса во вполне определенные временные рамки?
1) Я не различаю бюрократию и планирование. Это разные названия одного и того же процесса — придумывания «кому что делать когда что-то случится».
2) Мысль, которую я говорю (ещё раз повторить список?) сводится к тому, что никакими методами нельзя добиться гарантий временных рамок для восстановления сервиса.
Можно как-то формализовать прелюдию, можно как-то формализовать оповещения и то, что любят онкологи, 'expectation management', но вот сам процесс починки может в любой момент из рутинного превратиться в «творческий». В котором нет ни дедлайнов, ни каких-либо обещаний, ни гарантий. Только best efforts и то, если сильно надоедать не будут.
Разумеется, не все аварии такие. И бюрократия хорошо умеет справляться с авариями, о которых она подумала. Проблема реального мира и занятых бобров в том, что никакой бюрократии в принципе не хватит на то, чтобы предусмотреть всё. «В принципе» — это именно «в принципе». То есть не хватит и точка.
Сочетание бюрократии и прямых рук — ок, хорошо. Мало хаоса и много толку. К сожалению, бюрократия хочет быть не только непротиворечивой, но и полной, то есть исключать из рассмотрения такие вещи, как «в каком настроении сегодня старший системный администратор», или «нравится ли ему копаться в трейсах у явы», отрицая творческую часть процесса починки.
А потом горько плачется, мол, «не соблюли KPI» и грозятся всякими карами.
2) Мысль, которую я говорю (ещё раз повторить список?) сводится к тому, что никакими методами нельзя добиться гарантий временных рамок для восстановления сервиса.
Можно как-то формализовать прелюдию, можно как-то формализовать оповещения и то, что любят онкологи, 'expectation management', но вот сам процесс починки может в любой момент из рутинного превратиться в «творческий». В котором нет ни дедлайнов, ни каких-либо обещаний, ни гарантий. Только best efforts и то, если сильно надоедать не будут.
Разумеется, не все аварии такие. И бюрократия хорошо умеет справляться с авариями, о которых она подумала. Проблема реального мира и занятых бобров в том, что никакой бюрократии в принципе не хватит на то, чтобы предусмотреть всё. «В принципе» — это именно «в принципе». То есть не хватит и точка.
Сочетание бюрократии и прямых рук — ок, хорошо. Мало хаоса и много толку. К сожалению, бюрократия хочет быть не только непротиворечивой, но и полной, то есть исключать из рассмотрения такие вещи, как «в каком настроении сегодня старший системный администратор», или «нравится ли ему копаться в трейсах у явы», отрицая творческую часть процесса починки.
А потом горько плачется, мол, «не соблюли KPI» и грозятся всякими карами.
Мысль о том, что все предусмотреть нельзя — здрава. Но это не отменяет пользу бюрократии в обычных ситуациях, как вы правильно сказали, только не нужно давать ей возможность контролировать вообще все.
Если я правильно понял Ваш пример, он заключается в следующем: есть некоторая заложенная ошибка в ПО, которая при наступлении определенного события в будущем (прошествии периода времени, определенной даты («проблема тысячелетия») или выполнения ряда действий) приводит к необратимой потере данных, что даже восстановление из резервных копий не дает никаких результатов. Приводя данный пример, вы говорите, что все планы и «бюрократия» в этом случае идут лесом и надо просто дать время админу разобраться в случившемся, провести реверс-инженеринг программного обеспечения, найти ошибку в ПО и героически устранить ее.
Дак вот, плохая новость в том, что админ в таких ситуациях совершенно бесполезен. Точно также, как бесполезен офисный админ в вопросах «починки Интернета», когда проблемы в сети на M9, даже если в офиса 3 канала «Интернет» от разных провайдеров. Хорошая в том, что от него не требуется в таких ситуациях применять героизм и отвагу, а требуется обратиться к разработчикам/операторам связи и т.д. и привлечь их к решению данного вопроса. Планирование аварийного восстановления как раз и помогает заранее обозначить зоны ответственности и возможности по восстановлению, и согласовать их с руководством, чтобы в момент работы над аварией никто тебе не грозил «KPI». Этой темы я коснусь в третьей статье.
Также что касается заложенной ошибки в ПО я за свою практику знаю только об одном случае, когда это привело к потере данных — это отказ сверхнадежной и супердорогой СХД, когда через 3 дня разбора причин сбоя разработчики вендора признали, что допустили ошибку в коде, приводящую в определенных условиях к потере конфигурации СХД. Но этот сценарий проще, т.к. тут были регулярные ленточные бекапы и даже было хранилище попроще, куда все это можно было восстановить. Что касается ошибки в базе данных, которая приводит к невозможности восстановиться даже из корректно созданной резервной копии, то, на мой взгляд, в этом случае разработчики ПО будут кровно заинтересованы в том, чтобы устранить данный баг вне зависимости от наличия или отсутствия сервисного контракта, т.к. само по себе наличие возможности такой потери данных ставит крест на будущем данного продукта на рынке. Лично мне не известно ни одного случая приведенного вами сценария.
Дак вот, плохая новость в том, что админ в таких ситуациях совершенно бесполезен. Точно также, как бесполезен офисный админ в вопросах «починки Интернета», когда проблемы в сети на M9, даже если в офиса 3 канала «Интернет» от разных провайдеров. Хорошая в том, что от него не требуется в таких ситуациях применять героизм и отвагу, а требуется обратиться к разработчикам/операторам связи и т.д. и привлечь их к решению данного вопроса. Планирование аварийного восстановления как раз и помогает заранее обозначить зоны ответственности и возможности по восстановлению, и согласовать их с руководством, чтобы в момент работы над аварией никто тебе не грозил «KPI». Этой темы я коснусь в третьей статье.
Также что касается заложенной ошибки в ПО я за свою практику знаю только об одном случае, когда это привело к потере данных — это отказ сверхнадежной и супердорогой СХД, когда через 3 дня разбора причин сбоя разработчики вендора признали, что допустили ошибку в коде, приводящую в определенных условиях к потере конфигурации СХД. Но этот сценарий проще, т.к. тут были регулярные ленточные бекапы и даже было хранилище попроще, куда все это можно было восстановить. Что касается ошибки в базе данных, которая приводит к невозможности восстановиться даже из корректно созданной резервной копии, то, на мой взгляд, в этом случае разработчики ПО будут кровно заинтересованы в том, чтобы устранить данный баг вне зависимости от наличия или отсутствия сервисного контракта, т.к. само по себе наличие возможности такой потери данных ставит крест на будущем данного продукта на рынке. Лично мне не известно ни одного случая приведенного вами сценария.
знаете, у разработчиков, когда объем методологий и планирования начинает зашкаливать, есть фраза «ПИШИ КОД, БЛ.ТЬ». Тут то же самое. Зачем это все, если в конце концов все разгребает пара человек? Без планов, графиков и отчетов. Просто придут и сделают. Потом отчитаются об ущербе и что можно сделать, чтобы это не повторилось. Вот расскажите, чем ваша схема может ускорить подъем почтового сервера?
Приведенная схема зависимости точек отказа помогает:
1) В формировании плана локализации, который сокращает временя на определение отказавшего элемента.
2) В определении влияния отказа того или иного элемента на бизнес, для последующего обоснования перед руководством необходимости его резервирования.
3) В определении необходимых и достаточных компетенции для устранения последствий аварий. К примеру, если у нас упал гипервизор, то мы будем посреди ночи не только специалистов по виртуализации, но еще и спецов по прикладным системам, чтобы те потом проверили и в случае необходимости восстановили зависимые точки отказа.
Ну а что касается «ускорения подъема почтового сервера», то для этого есть несколько критичных условий:
1) Доступность резервов для восстановления.
2) Доступность компетенций для оперативных работ.
3) Проработанность процедуры аварийного восстановления.
И еще пара моментов, о которых речь пойдет в следующей статье.
1) В формировании плана локализации, который сокращает временя на определение отказавшего элемента.
2) В определении влияния отказа того или иного элемента на бизнес, для последующего обоснования перед руководством необходимости его резервирования.
3) В определении необходимых и достаточных компетенции для устранения последствий аварий. К примеру, если у нас упал гипервизор, то мы будем посреди ночи не только специалистов по виртуализации, но еще и спецов по прикладным системам, чтобы те потом проверили и в случае необходимости восстановили зависимые точки отказа.
Ну а что касается «ускорения подъема почтового сервера», то для этого есть несколько критичных условий:
1) Доступность резервов для восстановления.
2) Доступность компетенций для оперативных работ.
3) Проработанность процедуры аварийного восстановления.
И еще пара моментов, о которых речь пойдет в следующей статье.
Спасибо, теперь понятнее. Не ясно, как же оно будет на практике выглядеть, но может кому-то пригодится )
Забыл самое главное — данная схема позволяет дополнительно проверить, что вы не пропустили никакую из точек отказа. А то так часто бывает, что приготовились ко всему, а какую-то маленькую деталь из планирования упустили и именно она и стала причиной сбоя. Так, например, регулярно из зоны планирования аварийного восстановления упускаются всякие аппаратные ключи лицензий, которые в компаниях в одном экземпляре и без которых, естественно, ничего не работает.
Именно поэтому я вынес этап анализа в отдельную статью, т.к. в процессе планирования аварийного восстановления по моему опыту этот этап самый важный.
Именно поэтому я вынес этап анализа в отдельную статью, т.к. в процессе планирования аварийного восстановления по моему опыту этот этап самый важный.
Даже в совсем непредсказуемой ситуации разумная бюрократия несколько помогает, в вашем примере — автоматически подымаем недельный бэкап на другой виртуалке, саммоним админа, пока он исправляет ситуацию и ищет причину пользователи могут работать с почтой, когда появилась ясность — объединяем базы.
Только на днях словил похожую ситуацию, когда телефония сошла с ума и все звонки начали уходить на одного человека, т.к. был план на такие случаи, дежурный инженер спокойно откатился на суточный бэкап и компания продолжила работу в штатном режиме, я получил оповещение (был в пути и смог добраться только через 4 часа) спокойно нашел причину, починил, объединил базы звонков и записи разговоров, переключил на починенный вариант, ни какой паники и оборванного телефона по случаю что встали почти все процессы на предприятии. На сколько я понял топикстартера система не замена мозгам и прямым рукам, а дополнение.
Только на днях словил похожую ситуацию, когда телефония сошла с ума и все звонки начали уходить на одного человека, т.к. был план на такие случаи, дежурный инженер спокойно откатился на суточный бэкап и компания продолжила работу в штатном режиме, я получил оповещение (был в пути и смог добраться только через 4 часа) спокойно нашел причину, починил, объединил базы звонков и записи разговоров, переключил на починенный вариант, ни какой паники и оборванного телефона по случаю что встали почти все процессы на предприятии. На сколько я понял топикстартера система не замена мозгам и прямым рукам, а дополнение.
Хорошее начало, но маловата статья что-то. Даже для прелюдии.
Когда написал черновик, было даже много для одной статьи. Затем я выкинул из него булшит, эмоции, «искрометный» юмор, лишние детали, а также то, что все и так знают. После этого выпарил оставшуюся воду, выкинув из статьи выводы, которые все сами могут сделать, и, в конечном итоге, оставил только саму соль. Перестарался?
Не знаю, насчёт выкинутого контента, но в остатке из всего полезного осталась только схема. Возможно стоит уменьшить количество частей, но увеличить объём каждой, иначе можно сделать бразильский сериал с одним абзацем в каждой серии. Если я читаю статью, я ожидаю хоть какой-то логически завершённый объём знаний, информации, полезной нагрузки. Даже если статья предполагает продолжение, должна быть пища для размышлений над первой частью.
А сейчас ощущения передаются текстом об ошибке известного архиватора «Неожиданный конец архива».
А сейчас ощущения передаются текстом об ошибке известного архиватора «Неожиданный конец архива».
Зависимости точек отказа.
В терминологии ИБ это обычно соответствует Модели угроз — раздел целостность и доступность.
Вообще все давно рассказано. Есть стандарт Cobit по управлению IT, в нем как раз описаны стандарты эффективного управления IT, описаны уровни зрелости компании. Как правило управляемость ИТ в рядовых компаниях находится на уровне 0-1 — уровень Анархии. Вот как раз пример из комментов показателен.
Это когда что-то упало в почтовике и админы с шашкой наголо героически восстанавливают, как бог на душу положит. Никаких формальных процессов как действовать не предусмотрено.
В таком режиме пожарника и строится вся работа.
Конечно, все возможные ситуации описать и прикрыть невозможно, но можно описать и закрепить действия при выходе ситуации за рамки обычного. Случился крах ядра почтовика? Нет инструкции как это починять? В дело вступает инструкция «нештатная ситуация», по которой сисадмину дается час на попытку устранения «нештатки», после этого проблема уходит в платный саппорт продукта, который подключит все свои ресурсы, разрабов и ожидаемо -быстро- решит проблему.
А без такой инструкции сисадмин может и 2 суток пинать почтовик пытаясь понять в чем дело, раздавая обещания «вот щас щас разберусь в чем дело». Может разберется, а может и нет.
Вообще стандарт Cobit — это нечто непонятное за семью печатями и в общем случае недоступное обычному обывателю. Такой священный Грааль. Вы сами то его читали?
Ну скажем так Cobit, это довольно масштабная высокоуровневая вещь описывающая роли ИТ в бизнесе, поэтому с точки зрения практики может показаться довольно непонятной.
В принципе если вы оутсорсеры, то вам полезнее ориентироваться на стандарты ITIL (что вы и так наверняка делаете), Cobit это больше область службы Заказчика (или CIO).
В принципе если вы оутсорсеры, то вам полезнее ориентироваться на стандарты ITIL (что вы и так наверняка делаете), Cobit это больше область службы Заказчика (или CIO).
Что Cobit, что ITIL — это лучшие практики менеджмента, но в них, увы, содержаться лишь трактовки конечного результата, без инструкцию по их достижению.
Ни в коем случае не принижаю ценности и значения этих документов, однако помимо общих терминов в реальной жизни ты сталкиваешься еще и необходимостью разработки методологии по тому как составить ИТ-бюджет, провести анализ рисков, спланировать аварийное восстановление, или же сделать аудит ИТ-инфраструктуры или ИТ-отдела. Т.е. ты всегда стоишь перед вопросом как из состояния где ты находишься сейчас перейти в состояние по ITIL или хотя бы к его подобию. Собственно, эти процессы я и описываю в своих статьях.
Ни в коем случае не принижаю ценности и значения этих документов, однако помимо общих терминов в реальной жизни ты сталкиваешься еще и необходимостью разработки методологии по тому как составить ИТ-бюджет, провести анализ рисков, спланировать аварийное восстановление, или же сделать аудит ИТ-инфраструктуры или ИТ-отдела. Т.е. ты всегда стоишь перед вопросом как из состояния где ты находишься сейчас перейти в состояние по ITIL или хотя бы к его подобию. Собственно, эти процессы я и описываю в своих статьях.
Вторая часть: habrahabr.ru/post/226681/
Заключение: habrahabr.ru/post/228115/
Sign up to leave a comment.
Планирование аварийного восстановления. Часть первая