SRE. Путеводитель по надежности для неинженеров¶

Для кого эта книга¶

Эта книга для тех, кто слышал загадочное "эс-ар-и", и "эс-эр-и" и даже и "эс-эр-е" и не понимал кто это, что это и для чего это.

Эта книга для тех, кто считает в девятках некую "стабильность" и думает, что SRE придумал Google и "оно дорого и нам оно не нужно".

Эта книга для тех, кто подозревает, что "надежно" это не просто когда "всё работает", но не до конца понимает, как эту самую надежность измерить, а главное - зачем.

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

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

SRE это не модная аббревиатура, а целая инженерная дисциплина и философия, основанная на теории надежности, но расширенная и модифицированная для мира программного обеспечения и сервисов.

Если ты:

• Продуктовый менеджер, который хочет понять, почему инженеры против твоего гениального плана "запустить всё и сразу в пятницу вечером";
• разработчик, которому не интересно, как его код работает в проде, потому что ответственности за это у тебя нет;
• начинающий инженер или студент, для которого SRE - хайповый, но непонятный термин;
• тимлид, который чувствует, что команда тонет в "тушении пожаров", но не знает, как выстроить процессы иначе;
• руководитель, который измеряет стабильность в девятках и думает, что SRE - это как L3, но только почему-то в два раза дороже;
• просто любопытствующий, который хочет понять, что такое SRE и почему им так много платят :)

...то ты открыл нужную книгу :)

Если после прочтения ты поймаешь себя на мысли, что начинаешь смотреть на мир как инженер надежности (задумываешься о "точке отказа", когда стоишь в очереди в кофейне, или мысленно считаешь "девятки" доступности лифта в своём офисе) - я буду рад и буду считать свою миссию выполненной. Я так же признаю, что некоторые мои мысли могут стать поводом для здоровой дискуссии, пишите: philyuchkoff@gmail.com

Здесь не будет сложных формул (ок, будет парочка, но я их разжую) и заумного жаргона без объяснения. Будет много простых аналогий из жизни: такси, кофейни, парусные корабли, рестораны и даже законы строительства крепостей. Постараюсь перевести с инженерного на человеческий.

Эта книга попытка систематизировать и донести принципы SRE такими, какими я их увидел и понял. Изложенные здесь взгляды - результат моего общения с умными людьми, моего личного погружения в тему, огромного количества прочитанных книг, изучения опыта первопроходцев, изучения ГОСТов 27 серии, и собственных размышлений. И 29 лет опыта моего пути, начиная от ученика монтера по ремонту радиотелеграфного оборудования.

Цель книги не в том, чтобы сделать из вас Principal SRE после прочтения, я не буду грузить вас глубинами Linux Kernel или тонкостями поиска RowHammer для эскалации привилегий в твоем Kubernetes-кластере, а дам системное понимание надежности. Чтобы в следующий раз, когда кто-то скажет: "Нам нужно улучшить p^95-ю латенси до 150 мс, чтобы уложиться в SLO", или "Модель здоровья продукта основана исключительно на SLO и без этого не работает", вы не просто кивнули, а действительно поняли о чём речь, поняли, почему это важно для продукта и какова логика принятых для этого инженерных решений.

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