Файл: Дэвис Дженнифер, Дэниелс КэтринД94 Философия DevOps. Искусство управления it. Спб. Питер, 2017. 416 с. ил. Серия Бестселлеры OReilly.pdf

228
Часть IV. Инструменты достаточным запасом прочности. Чтобы избежать усталости, вызванной навязчивыми оповещениями, применяйте их только в случае наиболее зна- чительных инцидентов. Подробнее эта тема будет рассмотрена далее.
Срочность
Как и в случае с влиянием, далеко не все проблемы относятся к категории срочных, требующих безотлагательного решения. Срочная проблема тре- бует быстрого (иногда мгновенного) ответа. Например, «падение» вашего сайта, вызывающее потерю денег или клиентов, относится к категории проблем, требующих безотлагательного решения. Если же недоступен чисто информационный блог, вряд ли эта проблема требует столь срочного реше- ния. Конечно, у каждого представителя заинтересованной стороны имеется собственное мнение по поводу срочности той или иной проблемы, поэтому при настройке мониторинга или системы оповещений учитывайте мнение всех заинтересованных сторон.
Заинтересованная сторона
В первую очередь заинтересованными сторонами инцидента являются те, на кото этот инцидент воздействует. В частности, это могут быть заказчики
(или подгруппы заказчиков) или же группы сотрудников (в случае инци- дентов, связанных с внутренними службами). В качестве заинтересованных сторон могут также рассматриваться лица, ответственные за реагирование на инцидент. Например, если решение проблем, связанных с базами данных, находится в компетенции администратора баз данных, в случае возникно- вения этих проблем следует обращаться к нему, а не к эксплуатационной команде, которая в лучшем случае может вызвать администратора.
Ресурсы
Ответьте на вопрос о том, какие ресурсы нужны для реагирования на данный инцидент или оповещение и доступны ли они в данный момент. Достаточно ли у вас человеческих ресурсов, чтобы реагировать на несколько инциден- тов, или у вас имеется всего лишь один ответственный сотрудник по вызову, которого никто не может заменить? Имеются ли в вашей организации ре- сурсы, чтобы успешно работать без данной услуги, части оборудования или человека? Все это нужно учитывать при настройке системы оповещений.
Стоимость
Поддержка систем мониторинга и оповещений связана с определенными затратами. Следует учитывать стоимость услуг и решений мониторинга, стоимость поддержки пространства, используемого для хранения данных мониторинга и оповещений. Также нужно принимать во внимание стои- мость рассылки предупреждений людям, не говоря уже о расходах, связан- ных с реагированием на инциденты (с точки зрения реагирующей стороны).
Не следует забывать об убытках, понесенных компанией, в случае недоступ- ности какой-либо услуги.

Глава 11. Обзор экосистемы инструментов
229
В общем случае процесс рассылки оповещений заключается в создании событий на основе данных, собранных в процессе мониторинга. Обычно цель этого процес- са заключается в привлечении внимания человека к чему-то, что может потребо- вать вмешательства этого человека.
События
Управление событиями — это элемент мониторинга, который применяется к зна- ниям касательно влияния на системы и услуги. Для услуг, оказываемых в кругло- суточном режиме, это в общем случае отражает потребность в информации о со- стоянии разных компонентов инфраструктуры, получаемой в режиме реального времени. Система конфигурируется для мониторинга конкретной метрики или лога на основе определенного события. В случае превышения определенного по- рогового уровня или выполнения условий оповещения подается соответствующий сигнал или отсылается оповещение.
Подавляющая часть создаваемого программного обеспечения относится к катего- рии интернет-приложений, выполняющихся в круглосуточном режиме. При этом большое внимание уделяется обработке оповещений, появляющихся в нерабочее время. Один из способов выполнения подобной обработки заключается в как мож- но большем внедрении автоматизации.
Многие системы оповещения и мониторинга используют встроенные методы ав- томатического реагирования на события. Например, система мониторинга Nagios включает «обработчики событий», которые могут быть сконфигурированы с учетом различных условий оповещений. Эти обработчики могут выполнять различные действия — от автоматического перезапуска службы до создания распоряжения технику на замену отказавшего жесткого диска. Автоматизированные обработчики событий могут существенно сократить объем работы эксплуатационного отдела
(и объем сверхурочной работы), хотя использование таких обработчиков связано с определенными рисками. Важно убедиться в том, что условия сбоев четко опре- делены, а принципы работы обработчика событий понимаются настолько хорошо, что могут быть автоматизированы. Также нужны определенные гарантии в том, что автоматизация в большей степени решает проблемы, чем создает.
Ни одна из систем оповещений не является абсолютно точной во всех ситуациях.
Бывают ложные срабатывания, когда система генерирует событие при отсутствии реальной проблемы. Если появление таких событий приводит к рассылке опо- вещений, например специальных страниц, призванных разбудить сотрудников в нерабочие часы ради решения проблемы, это не очень хорошо. С другой стороны, если ложное срабатывание сопровождается инцидентом, не связанным с гене- рированием соответствующего оповещения, это может привести к затягиванию обнаружения и устранения проблемы. Как ложное срабатывание, так и ложное несрабатывание имеет свои отрицательные моменты. Что из них лучше, а что хуже, зависит от ваших конкретных проблем и среды.

230
Часть IV. Инструменты
Со временем, по мере получения сведений об истинном влиянии ваших про- блем и событий, вы захотите лучше настроить систему мониторинга и рассыл- ки оповещений. Рекомендуется отслеживать тенденции, проявляющиеся при генерировании оповещений, включая сведения о выполнении тех или иных действий в ответ на каждое событие, общее количество действенных опове- щений и количество оповещений, разосланных в нерабочее время.
Проектирование оповещений, или методы создания оповещений, которые пе- редают информацию людям в наиболее понятной форме, является непростой проблемой. В компании Etsy был создан инструмент OpsWeekly (https://github.
com/etsy/opsweekly), предназначенный для создания подобных оповещений и выполнения категоризации оповещений по типу и компоненту. Благодаря отслеживанию трендов оповещений и анализу данных оповещений можно резко улучшить эффективность оповещений и сделать счастливыми людей, призван- ных отвечать на них.
По мере накопления рабочего опыта приходит понимание того, какие опове- щения являются неважными. Довольно сложно обобщить создание автомати- зированного инструмента, который четко обрабатывает все варианты. Важнее продолжать работать над улучшением эффективности системы рассылки пре- достережений. Накопление усталости от оповещений, или десенсибилизация к оповещениям (обычно в случае ложного срабатывания), может привести к замедлению реакции на реальные проблемы, а также к выгоранию.
Среды постоянно изменяются. Все, что было проблемой прежде, перестает быть проблемой в случае изменения функции программы. Также к изменениям может провести рост сложности программного обеспечения, когда прежние методы ре- шения проблем больше не срабатывают. Люди склонны к быстрому решению про- блем, но алгоритмам не присуще подобное адаптивное поведение. Работа с этими постоянными изменениями является важным компонентом системы управления оповещениями и инцидентами.
Эволюция экосистемы инструментов
С течением времени проявляется тенденция к упрощению и устранению повторя- ющихся задач, чреватых появлением человеческих ошибок, из таких областей, как автоматизация установки сервера, а также конфигурирование и автоматизация инфраструктуры. Благодаря появлению своего рода «контейнеров» еще более упрощается «пайплайн», связывающий ваш ноутбук с производственной средой.
По мере того как автоматизация добавляется в разные части среды, обнаружива- ются новые шаблоны. Благодаря автоматизации инфраструктуры не столь важно придерживаться одной версии операционной системы. С точки зрения обеспе- чения безопасности больше пользы приносит развертывание нового экземпляра системы, включающего обновленные пакеты.

Глава 11. Обзор экосистемы инструментов
231
Благодаря непрерывной доставке и непрерывному развертыванию люди могут сосредоточиться на том, что действительно важно. Использование автоматизиро- ванных укороченных циклов обратной связи за счет автоматизации сборок дает нам дополнительную уверенность и понимание сути систем.
По мере адаптирования системы разработки приложений к критериям повышения эффективности продолжает развиваться экосистема инструментов. Если вы нач- нете перечислять вручную 12 факторов
1
, участвующих в разработке приложения, это будет то же самое, что и ручная настройка конфигурации серверов. Если будут стандартизованы и автоматизированы рабочие требования, сотрудники получат свободу выбора языка и рабочего шаблона.
Описанные выше тенденции позволяют концентрироваться на инструментах, ко- торые подчеркивают превосходство «мы» над «я», формировать взаимопонимание между командами и поощрять затраты времени на получение ценных результатов.
Выводы
В этой главе был выполнен обзор текущей экосистемы инструментов. В то время как эти инструменты являются важной частью devops-среды, важно подчеркнуть, что они усиливают межличностные и культурные аспекты этой среды, но никогда не смогут заменить их. Порядок использования инструментов, а также простота их использования влияют на принятие и распространение специфических аспектов культуры. Когда мы говорим о devops-инструментах, мы подразумеваем как сами инструменты, так и порядок их использования, а не только основные характери- стики этих инструментов.
Культура devops является одной из разновидностей сотрудничества между ко- мандами, организациями и отраслями. В процессе разработки решений важно представлять степень их влияния на команды и организации, а не только на от- дельных сотрудников. Иногда это означает коррекцию ожиданий в сторону блага для организации, работу в целях поиска решений, пригодных для всех, кто не яв- ляется «рок-звездами» организации, кто имеет решающий голос и может оказать положительное влияние на организацию в целом.
Инструменты devops подчеркивают преимущество «мы» над «я», позволяя груп- пам и организациям формировать взаимопонимание, необходимое для выпол- нения работы. Выбор инструментов, по сути, является выбором общего языка.
Приносит этот язык пользу организации в целом или подгруппам, входящим в со- став определенных команд? Порой из-за отсутствия хорошо сбалансированного инструмента выбор должен быть сделан в пользу команды, имеющей большую когнитивную ценность. Будьте осведомлены о ценности и чуткости к воздействи- ям со стороны вовлеченных команд.
1
https://12factor.net/