company_banner

Как Лёха стал инженером по SRE: выдуманная история про невыдуманные проблемы

    Направление Site Reliability Engineering становится всё более популярным. Хайп не на пустом месте: проблемы и задачи, которые решает SRE, действительно насущны для многих компаний.

    Популярность SRE растёт, но знаний о нём всё ещё недостаточно. Я не буду повторять формальные определения, а вместо этого расскажу несколько историй из жизни системного инженера Лёхи. Путь выдуманного Лёхи во многом похож на путь, который прошли реальные крупные компании, где впервые и возникли SRE-инженеры (даже если назывались иначе).

    Через историю Лёхи вы узнаете о задачах, которые решает SRE, и причинах, по которым для решения этих задач пришлось выделять отдельный класс инженеров.

    Глава 1. Hope is not a strategy

    Утро понедельника, инженеру эксплуатации Лёхе звонит разработчик Толя:

    — У нас проблема! Ошибки в сервисе «Плутон».

    — Подробности будут?

    — Там какие-то проблемы при работе с внешними ресурсами. Надо срочно починить! У нас всё лежит в проде.

    — Хорошо, сейчас посмотрим.

    За пару минут Лёха выясняет, что «Плутон» — это третьестепенный сервис, который обращается во внешние ресурсы и получает от них не очень важные данные. Обработка ошибок в нём не предусмотрена, поэтому если «Плутон» недоступен, то всё ломается. Плюс выяснилось, что до одного из внешних сервисов есть потери пакетов у магистрального провайдера.

    — Там потери у магистрального провайдера, часть запросов теряются.

    — Ну и? Когда починишь?

    — Эм, что? Это не у нас проблема, это у магистрального провайдера!

    — Ну значит, звони магистральному провайдеру, пусть срочно чинят!

    — Серьезно? Да им пофиг на нас. Могу позвонить в администрацию президента, толку и то больше будет…

    — Ну тогда звони нашему провайдеру, пусть с магистральным разберётся, мы платим за сетевое соединение, всё должно быть доступно на 100%!

    Станция пожаротушения в ЦОД Selectel
    Станция пожаротушения в ЦОД Selectel

    До перехода в эксплуатацию Лёха 3,5 года работал программистом. Он решил вспомнить прошлое и написал маленький патч для «Плутона» с возможностью автоматически выполнять retry в течение заданного времени.

    А диалога про 100% доступность могло бы не состояться, если бы Толик понимал: рассчитывать, что хоть один сервис в мире (да что там в мире, в галактике!) имеет 100% доступность, глупо. Сколько бы ты ни платил денег, это недостижимо. В погоне за 100% доступностью можно растратить весь бюджет, но так и не достигнуть её. Куда лучше быть готовым к нестабильности и уметь с ней работать.

    Леха понимает, что 100% доступность чего угодно невозможна, но он не разработчик, хоть у него и есть опыт работы разработчиком, это не его зона ответственности. Толик разрабатывает приложения и мог бы научить приложение работать стабильно в нестабильных условиях. Если приложение попадет в зону ответственности Лехи, то мы получим первого SRE

    Сложность систем и взаимодействия между ними, а также требование стабильной работы в нестабильных условиях привели к тому, что знаний одного только разработчика или инженера эксплуатации стало недостаточно. Требовались люди, которые сочетают в себе умения двух специальностей.

    «Почему никто не стремится к 100% доступности?» — спросил Толя

    100% доступность невозможна и бессмысленна. Надо исходить из предположения, что ошибки и сбои неизбежны, и также учитывать стабильность работы внешних компонентов, таких как браузер, мобильная ОС, сеть клиента, так как их надежность зачастую ниже даже 99%, и наши усилия будут незаметны для пользователя . Более того, предстоящие сбои надо учитывать при разработке и эксплуатации.

    Оценивая доступность, говорят о «девятках»:

    • две девятки — 99%, 

    • три девятки — 99,9%, 

    • четыре девятки — 99,99%, 

    • пять девяток — 99,999%.

    Пять девяток — это чуть больше 5 минут даунтайма в год, две девятки — это 3,5 дня даунтайма.

    Стремиться к повышению доступности нормально, однако чем ближе она к 100%, тем выше стоимость и техническая сложность сервиса. В какой-то момент происходит уменьшение ROI — отдача инвестиций снижается.

    Например, переход от двух девяток к трём уменьшает даунтайм на три с лишним дня в год. Заметный прогресс! А вот переход с четырёх девяток до пяти уменьшает даунтайм всего на 47 минут. Для бизнеса это может быть не критично. При этом затраты на повышение доступности могут превышать рост выручки.

    При постановке целей учитывают также надёжность окружающих компонентов. Пользователь не заметит переход стабильности приложения от 99,99% к 99,999%, если стабильность его смартфона 99%. Грубо говоря, из 10 сбоев 8 будет приходится на сбои, связанные с работой смартфона, а не самого сервиса. Пользователь к этому привык, поэтому на один лишний раз в год не обратит внимания.

    Глава 2. Нестабильность сохраняется

    Прошло несколько недель. Лёха расслабился и спокойно занимался привычной работой. 

    Но однажды вечером пятницы, за 20 минут до конца рабочего дня, в кабинет ворвался технический директор Иван Эрнестович.

    — Сударь, а вы осведомлены, что у вас приложение работает из рук вон плохо? Я бы даже сказал, отвратительно.

    Произносит он это без мата и криков, спокойным тихим голосом, отчего становится еще страшнее. Мониторинг не сообщал ни о каких инцидентах, поэтому придётся выяснять подробности.

    — Добрый вечер, Иван Эрнестович. А не могли бы вы рассказать, почему сделали такой вывод? Давайте начнём по порядку: о каком приложении речь?

    — Я сожалею, что вы не осведомлены о проблемах, но коль уж так, извольте слушать. Во время обеда с партнёром решил я рассказать ему про наш новый продукт «Русь». А он в ответ: «Да слышал я, и даже заходил поглядеть, но так и не дождался загрузки главной страницы». Я ринулся проверять и тут же сам убедился в его словах (лицо Ивана Эрнестовича изобразило отчаяние).

    — Мониторинг молчит, но я сейчас все проверю. Изволите ожидать, или отправить результаты расследования почтой?

    — Я подожду.

    Быстрый обзор системы мониторинга показал, что все показатели в рамках нормы. В частности, за последние 3 часа было всего ~ 1000 неуспешных запросов (неуспешными по мнению Лехи считаются только те запросы, на которые был получен 50x код ответа).

    — Проверил данные системы мониторинга, за последние часы было всего 1000 неуспешных запросов, новый сервис работает.

    — Сколько? И вы смеете называть это «работает»? Это недопустимый показатель!

    — Вы, как всегда, правы, Иван Эрнестович. 1000 неуспешных запросов — звучит грустно. Но это всего 1.5% от общего количества запросов. А это, согласитесь, не так уж и плохо.

    — Действительно, 1.5% не так страшно, но все ж почему мы не смогли открыть приложение?

    — А вы, говорите, обедали? В таком случае, проблема может быть не с нашим приложением, а с мобильным интернетом или Wi-Fi в ресторане.

    — Не исключено. Но 1000 запросов — это много, будьте любезны с этим разобраться.

    — Конечно, я уже завёл задачу, мы проведём диагностику и пришлём отчёт.

    — И прекратите пугать людей большими цифрами! Жду предложение по изменению системы мониторинга. Твоя идея с соотношением мне понравилась, надобно ее проработать.

    С этими словами Иван Эрнестович удалился, а наш герой Лёха выдохнул, дооформил задачу по инциденту, передал данные ночному дежурному и тоже удалился.

    К причинам инцидента и отчету мы вернёмся чуть позже, а вот историю про метрики вынесем как вывод к этой главе. После этого диалога Лёха придумал систему оценки качества работы продукта и за выходные её прописал.

    Фактически Лёха создал то, что сейчас обязательно используется в рамках SRE подхода:

    Целевые показатели: SLA, SLI, SLO

    Чтобы в следующий раз Иван Эрнестович не был удивлён, узнав о 1,5% проваленных запросов, Лёха выбрал ключевые метрики, по которым можно отслеживать, насколько стабильно работает наш сервис. Также предложил сразу установить для данных метрик границы, при пересечении которых команда, отвечающая за сервис, понимает, что все стало плохо и пора сфокусироваться над стабильностью.  И даже придумал название для таких метрик: соглашение о целевом уровне обслуживания — Service-Level Objective (SLO).

    Это соглашение позволяет всем в компании прийти к общему пониманию, что такое надежность (стабильность, доступность) системы. Потому что без него надёжность заботит только отдел эксплуатации. Разработчики ей пренебрегают, а для бизнеса это вообще абстракция, и цифры только путают.

    В SLO закрепляют целевые показатели доступности, которые вырабатывают вместе с продакт-оунером. То есть Лёха может их предложить, но утвердить не может. Здесь нужно согласие всех лиц, принимающих решение.

    Чтобы понимание было ясным, соглашение должно содержать конкретные числовые показатели — Service Level Indicator (SLI). Это может быть время ответа, количество ошибок в процентном соотношении, пропускная способность, корректность ответа — что угодно в зависимости от продукта.

    SLO и SLI — это внутренние соглашения, нужные для взаимодействия команды. Обязанности компании перед клиентами закрепляются в Service Level Agreement (SLA). Это соглашение описывает работоспособность всего сервиса и штрафы за превышение времени простоя или другие нарушения.

    Примеры SLA: сервис доступен 99,95% времени в течение года; 99 критических тикетов техподдержки будет закрыто в течение трёх часов за квартал; 85% запросов получат ответы в течение 1,5 секунд каждый месяц.

    Среднее время между сбоями и среднее время восстановления — MTBF и MTTR 

    Чтобы избежать претензий, Лёха пошёл дальше — сформулировал ещё два показателя: MTBF и MTTR.

    MTBF (Mean Time Between Failures) — среднее время между сбоями.

    Показатель MTBF зависит от качества кода. То есть чем меньше будет косячить разработчик Толя, тем лучше будет показатель MTBF. Но поскольку каждый косяк Толи влияет на Лёху, у Лёхи должна быть возможность делать ревью кода и, в случае совсем уж очевидных проблем, говорить «Нет!». 

    По крайней мере, это предполагает подход SRE. Он же предполагает понимание со стороны команды: когда SRE блокирует какой-то коммит, он делает это не из вредности, а потому, что иначе страдать будут все.

    MTTR (Mean Time To Recovery) — среднее время восстановления (сколько прошло от появления ошибки до отката к нормальной работе). 

    Показатель MTTR рассчитывается на основе SLO. Инженер по SRE влияет на него за счёт автоматизации. Например, в SLO прописан аптайм 99,99% на квартал, значит, у команды есть 13 минут даунтайма на 3 месяца. В таком случае время восстановления никак не может быть больше 13 минут, иначе за один инцидент весь «бюджет» на квартал будет исчерпан, SLO нарушено.

    13 минут на реакцию — это очень мало для человека, поэтому здесь нужна автоматизация. Что человек сделает за 7-8 минут, с тем скрипт справится за несколько секунд. При автоматизации процессов MTTR очень часто достигает секунд, иногда миллисекунд.

    Бюджет на ошибки

    Как мы выяснили, пытаться достичь 100% стабильности не самая лучшая идея, потому что это дорого, технически сложно, а часто и бесполезно — скорее всего, пользователь не оценит старания из-за проблем в «соседних» системах. 

    Поэтому Лёха предложил ввести еще одно понятие — бюджет ошибок. Это степень риска, которая допустима для данного сервиса, и ее можно прописать в SLO. 

    Бюджет на ошибки помогает разработчикам оценить, на чем нужно сфокусироваться в данный момент: на стабильности или новом функционале. 

    Если бюджет на ошибки содержит 43 минуты даунтайма в месяц, и 40 минут из них сервис уже лежал, то очевидно: чтобы оставаться в рамках SLO, надо сократить риски. Как вариант, остановить выпуск фич и сосредоточиться на баг-фиксах.

    Если бюджет на ошибки не исчерпан, то у команды остаётся пространство для экспериментов. 

    Чтобы не выйти за рамки, Error budget делят на несколько частей в зависимости от задач. Каждая команда должна оставаться в пределах своего бюджета на ошибки.

    Если это все будет внедрено, можно будет получить объективную картину, насколько стабильно работает наш сервис. Но остается одна серая зона: что делать, если бюджет на ошибки был исчерпан. 

    Лёха посчитал, что очень важно договориться об этом заранее и оформить в виде документа — Error budget policy. Для примера он решил зафиксировать, что при исчерпании бюджета на ошибки останавливается вся разработка бизнес-функционала и вся команда работает над повышением стабильности. Лёха уверен: этот документ позволит избежать конфликтных ситуаций в и без того напряженной ситуации.

    Леха закончил подготовку предложений и обнаружил, что уже вечер воскресенья, и уже совсем скоро опять на работу.

    Глава 3. Post mortem 

    Придя в понедельник в офис, первым делом Лёха открыл результаты расследования инцидента. Увиденное не радовало. Небольшая цитата:

    «В период с 14-00 до 18-00 наблюдались проблемы с сервисом “Русь”. Они были связаны с тем, что сервис “Плутон”, от которого зависит наш сервис, переезжал в другой ДЦ и были потери пакетов. Написали служебку на запрет проведения работ в рабочее время для команды разработки и эксплуатации сервиса “Плутон!”»

    Лёха грустно вздохнул: от такого расследования проку мало, и принялся писать свой отчет для Ивана Эрнестовича.

    «Иван Эрнестович, наши отчеты об инцидентах, как и система мониторинга, деструктивны. Я подготовил собственный отчет, предлагаю данный вид документа сделать стандартным и назвать его, допустим, post-mortem. Цель этого документа не найти виноватых, а понять, в каких процессах есть проблемы и как можно их улучшить!»

    Что и когда произошло

    16.10. 2015 19.45 поступила жалоба от Генерального директора о недоступности сервиса Русь, примерно в 16 часов.

    16.10. 2015 19.55 Инженер по эксплуатации Анатолий по данным системы мониторинга зафиксировал 1000 неудачных запросов в период с 14 до 17 часов. В момент поступления жалобы инцидент уже был разрешен. 

    Причины и факторы

    Нетехническая причина:

    Переезд одного из микросервисов, от которого зависит сервис «Русь» во время повышенной нагрузки, без предупреждения команды сервиса «Русь».

    Техническая причина:

    Отсутствие механизма повтора запросов у сервиса «Русь».

    Обнаружение

    Жалоба генерального директора.

    Решение

    Инцидент был обнаружен уже после завершения, вмешательства со стороны службы эксплуатации не потребовалось.

    Что прошло хорошо

    В системе мониторинга присутствовали все необходимые графики.

    В системе логирования был достаточный объем логов, чтобы установить причину появления неуспешных запросов.

    Что можно улучшить

    Разработать единую библиотеку, которая реализует функционал повтора запросов в случае кратковременной недоступности внешних сервисов. Данное решение было опробовано в рамках сервиса «Русь» и показало хорошие результаты.

    Доработать систему алертов, чтобы получать уведомления о проблемах не от пользователей.

    Внедрить метрики на основе соотношения успешных и неуспешных запросов.

    Где нам повезло

    Количество неуспешных запросов было 1.5%, и большинство пользователей не заметили проблему.

    Задачи

    RUS-347 — доработка системы мониторинга. Добавление метрик соотношения неуспешных запросов к общему числу запросов.

    RUS-354 — разработка библиотеки для реализации механизма повтора неуспешных запросов.

    Лёха сложил два документа в одно письмо и отправил их курьером Ивану Эрнестовичу, так как тот больше любил бумажные письма.

    Прошло несколько недель, наш инженер Леха уже отчаялся получить хоть какую-то обратную связь, и уже даже почти перестал расстраиваться из-за зря потраченного времени. И тут раздается звонок от Ивана Эрнестовича:

    «Алексей, я рассмотрел твои предложения и сделал вывод, что на текущем месте работы ты работаешь неэффективно. Ты мог бы принести больше пользы моей компании, поэтому я перевожу тебя на новую работу. Ты будешь инженером по стабильности — SRE. Даю тебе полгода, чтобы реализовать твои подходы и показать их эффективность».

    P. S. история может показаться утрированной, таковой она и является. Примерно такой путь прошли компании, которые придумали SRE. 

    Так чем же будет заниматься инженер по SRE Лёха

    1. Формировать целевые показатели надёжности системы и поддерживать их.

    2. Проверять и оптимизировать код, опираясь на знания о надёжности системы.

    3. Анализировать возникающие ошибки. Делать выводы, писать скрипты автоматизации для разрешения проблем.

    И это только малая часть обязанностей SRE-инженера. Если вам интересны подробности, то прочтите обзорную статью по SRE от Слёрма (выдержки из неё вошли в этот текст). В конце обзорной статьи вы найдёте ещё массу полезных ссылок.

    А если есть желание попробовать свои силы на практике, то приходите на интенсив. Там будет много практических кейсов и практикующие SRE-инженеры из крупнейших ИТ-компаний мира.

    Узнать подробности и записаться

    Автор статьи: Владимир Гурьянов — архитектор решений Southbridge, Certified Kubernetes Administrator.

    Southbridge
    Обеспечиваем стабильную работу highload-проектов

    Комментарии 14

      +2
      Действительно, очень выдуманная история.
      В реальной жизни письмо было бы таким:
      «Алексей, я рассмотрел твои предложения и сделал вывод, что на текущем месте работы ты работаешь неэффективно и компания вынуждена распрощаться с тобой. Передай все дела в течении двух недель новому сотруднику, по совместительству моему племяннику.».
        +1

        Ну это достаточно утрированное произведение и в реальной жизни, вряд ли было бы так просто и быстро.
        Но в целом, у меня в практике, да и у коллег, были кейсы где подобного рода предложения помогали развитию компании и карьерному росту:)

          +1
          В случае, если компания — госконтора, то да.
          А в нормальном, ориентированном на доходы, бизнесе я за 8 мест работы никогда «кумовства» не встречал. Если где-то руководители и приводили своих людей, то проверенных спецов с прошлых работ и претензий к ним не было.
          0
          Про доступность забавно — три девятки или пять? А зачем нам так много, всего же на 40 минут увеличивается доступность при очередном переходе.

          А потом оказывается, что у приложения/сайта каждый пользователь страдает, потому что одно открытие страницы загружает две сотни ресурсов и трогает триста внутренних сервисов, и при каждом открытии страницы статистически хоть что-нибудь да и лежит. Ну или не лежит, а просто тормозит, а “SRE” мониторит только средние или, если очень продвинутый 99-персентили (чего всё равно недостаточно, потому что см. выше)
            0

            Не совсем так, у мобильной сети и у мобильного телефона меньше девяток и если повысить стабильность приложения с 99 на 99.9999% то пользователь скорее всего не заметит разницы, потому что мобильная и сам телефон работают не так стабильно.

              +3

              Это так, если у вас всего один пользователь с его 99% доступности мобильника, но если у вас миллион пользователей и сервис недоступен 1% времени в случайные моменты, то это 10 000 пользователей попавших на проблемы.


              И повторю свой тезис другими словами — современный сайт или приложение зачастую делают как «микросервисы» и/или с большим количеством внешних зависимостей и, если не уделять этому особое внимание, то может оказаться так, что падение или деградация любого из сервисов или зависимостей ведёт к проблемам видимым у пользователя. Чтобы было понятно — если у вас 2 сервиса и вы мониторите каждый отдельно и у каждого доступность 99%, то итоговая доступность уже 98%, если же двадцать — то всего 81%, а в настоящее время не редкость и больше (я открываю главную хабра и получаю 260 запросов и это еще неизвестно во сколько запросов внутри двух десятков бэкендов разных компаний это выливается). В такой ситуации (пусть будет 100 отдельных сервисов) даже пять девяток каждого отдельного сервиса дают итоговую доступность всего 99.9% или проблемы у каждого тысячного пользователя, а если каждый открывает десяток страниц — каждого сотого.


              Вот и получается, что пять девяток не роскошь, а необходимость. И даже они дают всего лишь минимальное итоговое качество конечного продукта и задачей SRE и разработчиков становится обеспечить graceful degradation, когда отвал отдельных сервисов практически перестаёт на что-то влиять, а много девяток нужно поддерживать только у ключевых.

                +1
                Насовсем так.
                1. Смотрите, у вас есть микросервис А который зависит от 10 других. Допустим один из десяти является обязательным для микросервиса A и называется микросервис В. Так вот, если есть проблемы у микросервиса B, то это отразится и в показателях доступности микросервиса А, так как запросы к нему будут заканчиваться с ошибкой.

                2. Зачастую строют графики не только по конкретным микросервисам, но и по проекту в целом.

                3. При анализе работы используют еще и бизнесметрики. Например это может быть количество регистраций, количество бронирований или заказов.

                4. Так же, за частую используют метрики полученные напрямую от устройства клиентов.

                Приведенный вами пример, с математической точки зрения, верный и в целом не решен смысла. Но все не так линейно. И sli/slo это один из инструментов и на мой взгляд сильно переоцененный и работает он только в комплексе с большим количеством других инструментов и практик.
            • НЛО прилетело и опубликовало эту надпись здесь
              0
              Примеры SLA: сервис доступен 99,95% времени в течение года; 99 критических тикетов техподдержки будет закрыто в течение трёх часов за квартал; 85% запросов получат ответы в течение 1,5 секунд каждый месяц.

              Это все же примеры SLO, а не SLA. Примером SLA было бы кто кому и сколько платит за нарушение вышеуказанных метрик.
                0

                Позвольте не согласиться.


                « Соглаше́ние об у́ровне предоставле́ния услу́ги (англ. Service Level Agreement, SLA) — термин методологии ITIL, обозначающий формальный договор между заказчиком (в рекомендациях ITIL заказчик и потребитель — разные понятия) услуги и её поставщиком, содержащий описание услуги, права и обязанности сторон и, самое главное, согласованный уровень качества предоставления данной услуги.»


                Тут важно: согласованный уровень обслуживания. А санкции за не предоставления могут быть, а могут и не быть.


                Если очень просто: SLA это договор с заказчиком, SLO ,SLI это внутренний договор. Как правило SLO и SLI более строгие, по отношению к SLA.

                  +1
                  Использование методологии ITIL в качестве первоисточника знаний о SRE, скажем так, несколько странный подход. Может быть лучше прочитать SRE Book? Там SLA вводится так:
                  Agreements

                  Finally, SLAs are service level agreements: an explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs they contain. The consequences are most easily recognized when they are financial—a rebate or a penalty—but they can take other forms. An easy way to tell the difference between an SLO and an SLA is to ask «what happens if the SLOs aren’t met?»: if there is no explicit consequence, then you are almost certainly looking at an SLO.16


                  И еще сноска, которая под номером 16:
                  16Most people really mean SLO when they say «SLA.» One giveaway: if somebody talks about an «SLA violation,» they are almost always talking about a missed SLO. A real SLA violation might trigger a court case for breach of contract.


                  Вы можете с этим не соглашаться, но тогда у вас в статье не SLA в понимании SRE, а что-то другое.
                    +2
                    Использование методологии ITIL в качестве первоисточника знаний о SRE, скажем так, несколько странный подход. Может быть лучше прочитать SRE Book? Там SLA вводится так:


                    Понятие SLA появилось задолго до появления термина SRE и по этому давать определение не SRE вполне допустимо. Тем более, приведенное вам определение ни сколь не противоречит тому, что я привел.

                    SLA — это договор с внешними клиентами, который скорее всего предусматривает штрафные санкции.
                    SLO — это внутренний договор.
                      0
                      Ваша реализация SLA принципиально противоречит SRE.

                      Это нормально, и даже хорошо, когда методологии не следуют слепо, а адаптируют к реалиям. Очевидно, что для кого-то такой SLA нужен и полезен. Но если бы в статье была небольшая ремарка, что речь идет не о классическом SLA в понимании SRE, а о каком-то кастомном (или из другой методологии) решении, более подходящем к данному случаю — читающим было бы гораздо понятнее.

                      Я уже не в первый раз вижу/слышу такое понимание SLA (именно с точки зрения SRE), где речь идет о SLO для внешних клиентов. Сначала казалось, что люди просто не в теме. После еще нескольких повторов уже стало казаться, что это я что-то путаю. В этот раз я еще раз перечитал, что же написано в SRE. И SLA там все же про последствия и ответственность, а не про внешних клиентов.
                +2
                Управление надежностью — это нифига не специфика IT. Вообще, абстрактно, это подраздел управления рисками. Потому что надежность показывает вероятность наступления негативного события. Вложение денег в надежность (например увеличение запаса прочности балки моста) уменьшает вероятность наступления негативного события (разрушения моста при перегрузе). Но в тоже время увеличивает себестоимость. Бизнес получает возможность учитывать надежность как понятный ему параметр — доля в себестоимости (в случае моста). Ну а имея возможность учета — появляется возможность управления.

                IT компании следуют по уже проложенному пути — по мере роста прибыли, растет и ущерб в результате неожиданных сбоев. В начале источником неожиданных сбоев были разработчики выкатывающие изменения прямо на продакшн. Их изолировали от продакшна с помощью кьюэев. По мере роста сложности продуктов — скорость внедрения изменений упала ниже плинтуса. Разработчики задолбались бодаться с опсами и придумали сервисную, а потом и микросервисную архитектуры — и теперь целостность продукта стала попаболью опсов. Потому что продукт появляется не после сборки, а только после деплоймента. Так что SRE это еще одно подмножесто OPSов.

                Ну а история Лехи — свежо предание, да верится с трудом. Дев сообщает опсу про проблемы с сервисом в продакшне? Рилли? Типа опсы совсем мух не ловят, а девы их дублируют? Дальше. Компания внедряла SDLC задрачивая девов и кьюэев единственно правильным процессом, чтобы предотвратить деплоймент непроверенного кода. Но пришел опс Леха и зафигачил самописный патч прямо на продакшн. Судя по всему он был очень плохим девом, если за 3,5 года так и не смог запомнить SDLC. Да и способ решения выглядит не самым оптимальным — может все таки стоило добавить обработку ошибок? А если сервис третьестепенный — так может в первостепенных сервисах стоит ослабить зависимость от него? Ну чтобы все не ломалось при недоступности третьестепенного сервиса?

                По поводу доступности — для многопользовательских систем имеет значение не сбой для одного конкретного пользователя, а количество пользователей страдающих от сбоя в произвольный момент времени. Потому что часть пользователей обратится в поддержку. А это прямые расходы. И с ростом пользовательской базы — растут и расходы на их поддержку. И иногда переход от 99,99% к 99,999% означает уменьшение колл центра с 1000 операторов до 100. Что дает обоснование с точки зрения ROI.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое