SRE: как его понимают бизнес и разработчики09.11.2022 15:32

В сентябре Антон Скобин, коммерческий директор Слёрма, записал два выпуска подкаста «Манул Слёрма» с Олегом Блохиным, лидером инфраструктурной команды Dodo Engineering. Поговорили о том, как выстраивается работа SRE-команд, какие функции они выполняют и в чём профит от SRE для бизнеса. В этой статье поделимся главными мыслями этой беседы.

Баланс расходов и доходов

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

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

Если говорить о Dodo, то тут действительно падения в прайм-тайм ведут к потере денег. А новые фичи могут повлиять на увеличение дохода, а могут и не повлиять.

Поиск баланса с помощью SRE — это только вершина айсберга. На самом деле SRE — это сплав практик, процессов и мировоззрений, которые вместе дают инженерную и бизнесовую перспективу и понимание, как делать надёжные приложения и релизиться быстро.

Надёжность приложения — это тоже фича

Фокус на надёжности зависит от проекта. То, что простительно стартапу, не всегда простительно сервису федерального уровня. SRE может многое дать, если нужно, чтобы надёжность стояла во главе угла.

И в этом плане надёжность — тоже фича. Во многих компаниях SRE культивируют именно для фокуса на нефункциональных требованиях, которые с точки зрения бизнеса не так понятны, как со стороны инженерной части. Например, время открытия сайта. Допустим, он загружается за 100 мс. Бизнес чаще всего на это не смотрит — сайт открывается быстро и это хорошо. На самом деле эти 100 мс могут стоить очень дорого. Но иногда борьба за сокращение с 300 мс до 100 может быть настолько дорогой, что не имеет никакого смысла.

Бывает и так, что инженерам ставятся нереалистичные задачи, когда требуется надёжность намного выше, чем есть в текущий момент.

В 2017 году в Dodo с этим были проблемы, а команда только начала изучать книгу от Google. Один из лидеров команды утверждал, что наш показатель надёжности должен быть выше 99,999%, хотя таких показателей тогда не предлагала ни одна база и ни одно облачное хранилище. А как строить систему с 99,999%, если в инфраструктуре ничего для этого не готово и если используются инструменты, которые не дают нам даже четырёх девяток? Если чётко следовать книжке, нужно было бы стопнуть разработку и заниматься только повышением надёжности, пока цель не будет достигнута. Но такой шаг далёк от реальности, поэтому потребовалось искать компромисс, чтобы разработка могла двигаться дальше.

Смысл SRE сводится к тому, чтобы, удерживая надёжность на каком-то выбранном уровне, обеспечить максимально возможную в этих условиях скорость доставки за минимальную себестоимость инфраструктуры и использования новых технологий. Даже если сейчас компанию устраивает надёжность, это не значит, что внедрение SRE бессмысленно. Эти практики в том числе помогают договориться внутри компании, какой уровень надёжности вам нужен.

Другие подходы и здравый смысл

Хоть практики SRE и показывают эффективность, это не единственный подход, который решает вопрос стабильности. В 2000-х существовало огромное количество практик, которые не привязаны к SRE. Системные администраторы в 90-х тоже обеспечивали надёжность, но другими способами, которые можно применять до сих пор. 

Можно взять DevOps, поставить во главу угла скорость доставки, и метрики надёжности всё равно всплывут из-за рационального мышления. Станет заметно, что мы как-то быстро доставляем и слишком часто падаем. Те же практики, которые относятся к принципам SRE, вполне относятся и к другим подходам. Главный из них — давайте сделаем так, чтобы работало, а так, чтобы не работало, делать не будем.

Отличие в том, что если в компании есть SRE-команда, то вопрос находится в повестке дня и осознан, по нему применяются решения. Не случается так, что никто в компании об этом не подумал.

Чем занимаются SRE в Dodo

SRE-команды в разных компаниях устроены по-разному и выполняют разные задачи. В Dodo SRE отвечают за имплементацию инструментов и набор практик, а ещё:  

• создают инфраструктуру, которой  будут пользоваться другие команды;

• обучают команды. Если сделали новый инструмент, то объясняют другим принцип его работы, пишут документацию;

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

Ответственность за то, что нужно делать команде и к чему это всё приведёт, лежит на лидере. Когда лидер не занят менеджерскими задачами, он точно так же подключается к инцидентам в качестве инцидент-командера или специалиста по инфраструктуре. Дежурит, как и все в команде. Так исторически сложилось, что SRE в Dodo ближе к инфраструктурным вопросам, но так не во всех компаниях.

Ещё одна из целей — чтобы команда SRE сильно не разрасталась в зависимости от размера компании. Для этого существуют свои инструменты, которые не требуют постоянного внимания и поддержки. Например, репозиторий, в котором любая команда может самостоятельно создать продакшен-инфраструктуру или девокружение. Поскольку ошибиться там всё ещё возможно, существует процесс пулреквестов, за которым следят инженеры команды.

Также существует отдельный репозиторий по пушмодели, в который можно закоммитить один файл и на одном из окружений развернётся приложение. Можно закоммитить 100 файлов и развернётся 100 приложений. Однако и этот удобный инструмент требует внимания, так как не все умеют работать с этим репозиторием.

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

Кто инициирует и внедряет SRE в команды, бизнес или инженеры

Инициатива внедрить в компании практики SRE должна исходить от инженера. Маловероятно, что человек из бизнеса наткнётся где-то на книжку от Google, прочитает про SLI, SLO и SLA, придёт к инженеру и скажет: «Ребята, я нашёл. Давайте вот так делать». Даже если такое произойдёт, то договориться и убедить будет сложнее.

Надёжность приложения в интересах самих инженеров, иначе они сами же потонут под количеством работы, которая генерируется другими отделами. Ценность SRE как методологии ещё и в моральной стороне. Она культивирует инженерный подход к решению проблемы и вбивает в голову, что надежда — это не стратегия. Должен всегда быть план «Б».

Также SRE даёт набор вопросов и способов мыслить о проблеме, с которыми намного проще приходить к бизнесу и находить решения. Конечно, книга сама по себе этого не даст. Всё достигается опытным путём. Если вы уже крутой технический специалист, возможно, что вам не нужно никакого SRE. Но вы можете получить пользу от того, что методология по-другому структурирует ваши знания. Возможно, что вам не хватает только одного вопроса, который нужно задавать менеджменту, чтобы найти общий язык.

SRE и корпоративная культура

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

SRE сам по себе не решает вопрос культуры, но с его помощью можно договориться об общих метриках. В IT-компаниях довольно много квалифицированных людей, которым, к сожалению, спускают задачи сверху и говорят, что делать. Хотя их можно собрать и сказать: «Вот так мы будем оценивать вашу работу. Творите». Иногда это работает лучше.

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

Где и как узнать больше о SRE

© Habrahabr.ru