Visitors have accessed this post 3018 times.
Visitors have accessed this post 3018 times.
Автор — Евгений Генеральчик
Генри Форд был классный чел. Правда, не знаю, сам он дошел до такой славной мысли или услышал о подходе, когда-то использовавшемся у китайских медиков. Ведь пока в древней варварской Европе самым эффективным лечением считалось кровопускание, в не менее древнем Китае, чтобы медики не увеличивали время лечения пациентов и число назначаемых процедур, им начали платить за те дни, в которые к ним НЕ обращались.
Однако к Форду. Форд платил ремонтникам только за то время, когда они бездельничали, ведь раз они бездельничают — на заводе нет неисправностей и производство идет как надо. Если же происходил какой-то инцидент, то загоралась лампочка, которая горела до исправления оного, а оклад ремонтников уменьшался пропорционально времени простоев.
В реалиях современного общества наиболее применимым такой подход оказался в области, которую Google по-умному назвал SRE (Site Reliability Engineering). Казалось бы, при чем здесь Форд? Тем ремонтникам платили за то, что они ничего не делают, а SRE должен вкалывать как пресловутый папа Карло. Давайте разбираться дальше.
Дело в том, что Форду нужно было, чтобы красная лампочка не горела (то есть, чтобы не было вынужденных остановок на производстве). Это заставило ремонтников выработать новые схемы работы и правила. Они начали больше общаться с рабочими у станков, чтобы получать своевременно информацию о состоянии оборудования. Стали работать на упреждение, проверяли, чтобы станок не сломался в самый неподходящий момент, выполняли всякие там ТО и, что очень важно, уменьшали время обработки инцидентов за счет многократных повторений. Они соблюдали четкий порядок действий при устранении отказа, пользовались стандартным инструментом, использовали оригинальные запчасти. В результате Форд даже аплодировал им из своего кабинета, ведь они обеспечили бесперебойную работу завода или, по крайней мере, минимизировали время устранения аварий.
А теперь давайте посмотрим на те правила, которые выработала для себя бригада ремонтников Форда (и сравним их с основными принципами DevOps и SRE).
| Ремонтники Форда | DevOps | SRE |
| Взаимодействие с рабочими | Сократить разрозненность в организации | Делитесь с разработчиками, используйте одни и те же инструменты и методы во всем стеке |
| Работа на упреждение (тренировка отказов) | Принимать неудачу как нормальное явление | Разработайте формулу для балансировки несчастных случаев и отказов с новыми выпусками |
| Внедрение полезных изменений | Осуществлять постепенное изменение | Поощряйте быстрое движение за счет снижения затрат на отказ |
| Универсализация инструментария | Используйте инструменты и автоматизацию | Призывает «автоматизировать работу в этом году» и свести к минимуму ручную работу систем, чтобы сосредоточиться на усилиях, которые приносят долгосрочную пользу системе. |
| Подбор и проверка деталей | Измерить всё | Считает, что эксплуатация — это проблема программного обеспечения, и определяет предписывающие способы измерения доступности, времени безотказной работы, простоев, трудозатрат и т.д. |
Выходит, DevOps и SRE делает то же самое, что ремонтники? Нет. Считается (хотя должно не считаться, а так и быть на самом деле), что та система, за которой наблюдает SRE, должна быть максимально автоматизированной и самовосстанавливающейся. Сегодня создано грандиозное количество инструментов, для того чтобы создать такую систему. Есть DevOps-философия/методология, IaaC и IaaS, CI/CD. Есть даже такая штука, как NoOps, которая подразумевает, что не нужна и микросервисная архитектура, можно просто забросить код провайдеру, обозначить, как это должно работать (на какой порт принимать запросы, какие параметры принимать, какие данные получать) и вуаля — есть готовый сервис, который что-то там обрабатывает и выдает результат.
А еще есть многолетняя история системных администраторов, которые являются прообразом SRE, по моему мнению. Если оглянуться на пару-тройку десятков лет назад, то мы увидим того самого SRE в первом представлении гугла — человек (довольно часто — разработчик), разбирающийся в функционировании работающих систем и обеспечивающий их надежность, меняющий архитектуру, оказывающий влияние на инфраструктуру, реагирующий на изменения требований и показателей и, разумеется, разбирающийся с инцидентами. Все это преследует только одну цель — спокойно наслаждаться музыкой, попивая чай на мягком диване в центре рабочего цеха!
И еще один интересный факт: SRE, который развивался в Google (изначально для удовлетворения внутренних гугловских потребностей) начинает свою историю где-то в начале 2000-х. Так что да, SRE древнее DevOps (первый DevOpsConf прошел в 2007, тогда же появилось название этой философии-методологии, а зародилась она всего на полгода-год раньше). Можно сказать, что SRE стимулировал появление DevOps-философии, потому плотно с ней переплетен, воплощает ее, но имеет гораздо более жесткие предписания относительно способов измерения и достижения надежности. Запутанно получилось… Попробую проще: SRE объясняет DevOps, что и как нужно делать, чтобы достигнуть лучшего, надежного результата.
Выходит, сисадмины (те самые олдскульные, бородатые, свитератые и т.д.) — это SRE? Отчасти. Как мне кажется, SRE взяли от сисадминства и от DevOps лучшие черты. И теперь все выглядит так, будто SRE — это направленный на уменьшение затрат при простоях DevOps-инженер. Он еще планирует, и этим компенсирует простои вне зависимости от причин — задержка при обновлении, кривизна рук при эксплуатации, землетрясение, извержение вулкана, нападение инопланетян. Нет разницы, что произошло, главное, чтобы система самовосстановилась с минимальными простоями и потерей данных. И совсем идеально будет, если это произойдет полностью автоматически, а SRE просто увидит на каком-нибудь графике, что где-то что-то произошло и само починилось. Только не само, конечно, а усилиями правильно отработавшей автоматизации, написанной тем самым SRE. Но как можно спланировать и главное скомпенсировать простой? Для этого существуют не особо секретные, любой гугл знает какие, метрики SRE.
Я думаю, многие сталкивались с термином SLA (Service Level Agreement), он нам знаком еще по ITIL. В SLA закрепляются обязанности компании перед клиентами. Это соглашение описывает работоспособность всего сервиса и штрафы за превышение времени простоя или другие нарушения.
А есть еще такие метрики как SLI и SLO (Service Level Indicators и Service Level Objectives). И с ними все просто: SLI (та самая лампочка) показывает, сколько времени тратится на каждый инцидент (авария, обновление, технические работы, пропускная способность, количество неотвеченных запросов — все это тоже пересчитывается в виде времени), а SLO — это целевой показатель на основе SLI, о котором договорились заинтересованные стороны (сколько минут лампочка должна НЕ гореть в месяц/квартал/год).
Google утверждает, что важнейшими компонентами SRE являются toil, toil budget и то, что может уменьшить toil. Под toil подразумевается «работа, которую не хочется делать» — работа над проблемами и просто какие-то ручные действия, которые нужно выполнить. Унылый периодически повторяющийся труд — это toil, соответственно, toil budget — это время, запланированное на toil. Google старается отводить на toil около 50% времени своих инженеров. Соответственно, toil budget будет составлять 50% времени в неделю/месяц/квартал/год — какими сроками удобнее оперировать. То есть, если человек работает восемь часов в день, пять дней в неделю в составе команды из еще четырех человек, то toil budget для команды составит 5дней*(8часов/2)*(4+1) = 100 часов в неделю на команду.
Однако следует учитывать, что главная опасность для toil budget — проблема, она набрасывается откуда-то из-за угла и начинает грызть бюджет со страшной силой.
Давайте представим какую-то абстрактную проблему, на решение которой уходит 10 минут. Однако сначала она появляется. Проходит несколько минут, пока эту проблему заметит система мониторинга и оповестит нас каким-нибудь алертом. Еще несколько минут уйдет на то, чтобы разобраться, где именно эта проблема произошла и как ее решить. Теоретически на работу потрачено 10 минут, а фактически — проблема была решена за 15 минут. Это приводит нас к еще одной интересной метрике — MTTR (Mean Time To Recovery), среднее время восстановления. Название говорит само за себя — сколько времени прошло от появления ошибки до возвращения системы к нормальному состоянию. Если этот показатель высок, значит, обработка инцидентов недостаточно автоматизирована. Вместе с MTTR упоминается и еще одна важная метрика MTBF (Mean Time Between Failures) — тоже говорящее название, среднее время между инцидентами. Если инцидентов много — значит, код был написан криво, и это сейчас не камень в сторону разработчиков, DevOps-инженеры тоже сейчас пишут, правда, больше на yaml, но это уже частности.
Весьма важным аспектом применения SRE является понимание и пересчет этих метрик. И такой приятный момент — не обязательно на бумаге быть SRE, чтобы эти метрики высчитать. Просто посидеть и проанализировать свою работу, работу команды, посмотреть, сколько времени тратится на решение инцидентов, сколько на остальную работу и сколько на чай и просмотр котиков на youtube.
Только на этот раз не про ремонтников. Мы ведь договорились, что SRE — не ремонтники, хотя и придерживаются похожих принципов. Форд мог в любой момент собрать всех руководителей компании и, не обращая внимания на их отговорки, отправить их в двухнедельный круиз. И если работа без начальника шла хорошо, его ждало поощрение. Тех же, кто не смог организовать самостоятельную работу подразделения, Форд увольнял. Не каждый работодатель будет возить SRE в круизы, но многие постараются найти его в отпуске, даже если для этого придется дозвониться на выключенный телефон. От Генри Форда к сисадминам, от сисадминов в SRE пришел самый важный принцип — сделать работу так, чтобы не было никакой работы. Все ведь знают, что хороший админ (а теперь и SRE), — это тот, который ничего не делает. Потому что если он что-то делает, значит, что-то работает неправильно, а если он бездельничает, значит, ему не о чем беспокоиться. Чего, коллеги, вам и желаю.
Мнение редакции может не совпадать с мнением автора.
Если вам интересно посещать бесплатные онлайн-мероприятия по DevOps, Kubernetes, Docker, GitlabCI и др. и задавать вопросы в режиме реального времени, подключайтесь к каналу DevOps by REBRAIN.
*Анонсы мероприятий каждую неделю
Практикумы для специалистов по инфраструктуре и разработчиков — https://rebrainme.com.
Наш Youtube-канал — https://www.youtube.com/channel/UC6uIx64IFKMVmj12gKtSgBQ.
Агентство Fevlake, проектируем и поддерживаем IT-инфраструктуры с 2012 года — https://fevlake.com.
В некоторых случаях может потребоваться удалить ненужные директории и файлы, чтобы освободить место на жестком диске. Рассказываем, как это сделать.
Для удаления файлов используется команда rm. Предупреждение: удаление файлов и каталогов в Linux с помощью команды rm является необратимым. Поэтому следует проявлять особую осторожность при ее...
Во время устранения неполадок служб, работающих на ОС Linux, просмотр открытых портов является одной из задач, которую должен выполнять любой пользователь или администратор. Если служба должна по идее работать, но по какой-то причине она не работает, то, скорее всего, порт этой службы закрыт и его нужно открыть.
В этом туториале мы покажем, как...
Ищете способы, как контролировать производительность сервера Linux? В большинстве дистрибутивов Linux уже встроены разные инструменты мониторинга. Используя их, можно посмотреть метрики с информацией о системных процессах. Эти инструменты можно использовать для поиска возможных причин возникновения проблем с производительностью. Команды, которые...