Как построить надёжную инфраструктуру и не сгореть: курс, который меняет подход к стабильности
Бывает так: прод ночью, дежурство, уведомление от PagerDuty, потом ещё одно — и завтра снова то же самое, что и вчера. Работать с инфраструктурой не просто профессия — это ответственность, напряжение, порой героизм. И если вы уже не новичок, если умеете развернуть систему, мониторить её и даже чинить на лету, то рано или поздно возникает вопрос: «А можно ли по-другому? Не тушить пожары, а предотвращать их?»
Короткий ответ: «Да, можно». Именно тут на сцену выходит Site Reliability Engineering.
Бывает так: прод ночью, дежурство, уведомление от PagerDuty, потом ещё одно — и завтра снова то же самое, что и вчера. Работать с инфраструктурой не просто профессия — это ответственность, напряжение, порой героизм. И если вы уже не новичок, если умеете развернуть систему, мониторить её и даже чинить на лету, то рано или поздно возникает вопрос: «А можно ли по-другому? Не тушить пожары, а предотвращать их?»
Короткий ответ: «Да, можно». Именно тут на сцену выходит Site Reliability Engineering.
Примечание Adviser
В этой статье ссылки партнеров. Это значит, что если вы что-то покупаете с нашей помощью — вы также поддерживаете dev.by. (Вот другой способ).
При этом редакция и авторы независимы в выборе темы, концепции материала, фокуса описания, подхода к услугам или товарам. Прежде чем что-то советовать, мы много читаем и смотрим по теме, говорим с экспертами.
Редакция может выражать свое мнение и пробовать всё на себе.
Если рекомендательный материал обновляется, мы указываем, что и когда поменялось, в самом начале.
Site Reliability Engineering (SRE) — подход, который появился в Google не как модный тренд, а как вынужденная мера. Когда инфраструктура становится слишком сложной, а количество пользователей и сервисов — слишком большим, нужен метод, позволяющий управлять стабильностью осознанно. Не на уровне интуиции, а на уровне метрик и договорённостей. Сегодня SRE — не просто набор практик, а философия, которая помогает превращать хаос в управляемую систему.
Если чувствуете, что готовы выйти на новый уровень — этот курс от Google Cloud именно для вас.
Переход от интуиции к управляемой надёжности
В традиционном подходе стабильность воспринимается как нечто само собой разумеющееся. Пока работает — хорошо. Как только перестаёт, включаем Slack, созваниваемся, чиним. Но в мире современных распределённых систем этого недостаточно. Надёжность — такая же характеристика системы, как скорость или масштабируемость. Она должна быть измерима и управляема.
Именно это даёт вам подход SRE. Он предлагает отказаться от субъективных оценок и перейти к конкретным метрикам: SLIs (индикаторы уровня сервиса) и SLOs (целевые значения). Вы больше не говорите: «У нас всё в порядке», вы говорите: «Наша доступность — 99,95%, и мы укладываемся в error budget».
Такой подход меняет мышление. Он позволяет вам и вашей команде принимать обоснованные решения: где стоит усилить инфраструктуру, а где — остановиться и не тратить ресурсы. Вы больше не гадаете, вы управляете.
Что умеет инженер, знакомый с SRE
Если вы работаете с инфраструктурой, то наверняка знаете, как сложно доказать, что система требует доработки. Или объяснить, почему не стоит прямо сейчас выкатывать новую фичу, потому что надёжность уже на пределе. Site Reliability Engineering помогает выстроить мост между инженерами и бизнесом. С его помощью можно не просто спорить, можно аргументировать. Вы получаете возможность показать на цифрах, что система не выдерживает, или наоборот — что всё идёт по плану.
Вместо постоянного «давайте просто починим» появляется пространство для взвешенных решений. SRE — это про зрелость. Про умение сказать: «Эта система достаточно надёжна, и этого достаточно». Или: «Мы превысили error budget, нужно сфокусироваться на стабильности».
Такие навыки выходят далеко за рамки конкретной платформы или стека. Это подход, который можно применить где угодно: в облаке, на on-prem, в стартапе, в корпорации. Он становится частью вашего профессионального мышления.
Если вы хотите погрузиться в эти принципы с умом и практикой, обратите внимание на курс Site Reliability Engineering: Measuring and Managing Reliability от Google Cloud на платформе Coursera. Это не «ещё одна теория», а курс, который системно и по шагам объясняет, как измерять и управлять надёжностью сервисов.
Программа состоит из семи модулей, и каждый из них — логичный шаг в освоении SRE. Сначала вы разберётесь в базовых понятиях: что такое SLO, как формулировать SLIs, в чём разница между ними и SLA, и почему это не просто формальности. Затем углубитесь в практику: научитесь строить error budget, анализировать надёжность как характеристику продукта, выбирать правильные метрики, а не те, которые «просто удобно собирать».
Особое внимание уделяется пользовательскому опыту. Вы не просто выбираете показатели вроде аптайма, вы учитесь думать категориями юзер-джорни — от первого запроса до получения результата. Ведь именно здесь рождается восприятие «работает или нет».
Кроме того, курс показывает, как документировать SLO-политики, вести переговоры по error budgets и договариваться внутри команды. Это даёт основу для того, чтобы внедрить SRE-практики в реальной рабочей среде, а не просто на бумаге.
Программа включает в себя видеолекции, практические задания, обсуждения, а главное — живые и актуальные примеры, основанные на реальных сценариях. Материал подаётся понятно, даже если английский не родной — язык курса ясный и структурированный.
Уже почти тысяча студентов оставили курсу высокую оценку — 4.5 звезды из 5. Это один из самых признанных и сбалансированных курсов по теме SRE, и он определённо стоит вашего внимания.
Время, когда можно было просто настраивать мониторинг и надеяться, что ничего не сломается, прошло. Современные системы требуют зрелого подхода к стабильности. Если вы хотите перестать быть просто инженером поддержки и стать специалистом, который проектирует устойчивые, надёжные, масштабируемые решения — SRE-подход должен стать вашей новой базой.
TIP от Adviser: Учиться на Coursera выгоднее с подпиской Coursera Plus. За $59 в месяц можно пройти неограниченное число учебных программ из более чем 7 тысяч. Это идеальный вариант, если вы готовы посвятить много времени учебе.
С маленьким ребёнком на удалёнке: сколько стоит час тишины дома, в коворкинге и в мини-офисе
Индийская IT-компания во время пандемии отправила больше 10 тысяч сотрудников по домам. Сидеть за работой они стали дольше, в основном сверх обычных часов, а успевали примерно столько же или чуть меньше: продуктивность упала на 8–19%. Сильнее всех просели те, у кого дома были дети.
Кто садится за ноутбук первый раз за день, уложив ребёнка, знает это и без исследований. Но стол на кухне бесплатный, а коворкинг стоит денег. Поэтому уходить из дома или нет, обычно решают финансы.
Вы много сделали, но никто этого не заметил. Как показать, на что повлиял ваш код
«Руководитель, каким бы замечательным он ни был, вероятно, тоже не помнит всего, что вы сделали», — пишет Джулия Эванс, разработчица и автор блога о программировании. Она советует записывать все результаты и рядом с каждым ответ на вопрос, можно ли привязать к нему цифры.
Попробуем разобраться, как найти такие цифры для кода, что мерить, если работа не про выручку, и о чем рассказать на грейд-ревью вместо списка тикетов.
Агенты пишут код, который приходится читать разработчикам. Как не утонуть в ревью
На бумаге использование агентов выглядит отлично: в компаниях, внедривших AI в разработку, строк кода стало больше на 30%, а запросов на слияние на 23%. Но эти метрики никак не учитывают, дошло ли что-нибудь до пользователей. Исследователи из Гарварда заглянули в Jira и не нашли значимого роста закрытых задач — разница застревает в ревью.
В статье попробуем разобраться, что считать вместо строк кода и как разгрузить ревьюеров.
«Этот код выглядит ужасно, но работает». Что чинить первым, а что лучше не трогать
«Худшая стратегическая ошибка, какую может совершить софтверная компания», — так в апреле 2000 года Джоэл Спольски, сооснователь Fog Creek Software, назвал решение Netscape переписать код с нуля. С выхода версии 4.0 прошло почти три года, а версии 5.0 так и не случилось. Соблазн снести «ужасный» модуль знаком каждому, кто открывал чужой код ради мелкой правки.
Хотите сообщить важную новость? Свяжитесь с редакцией через страницу контактов
Главные события и полезные ссылки в нашем Telegram-канале
Обсуждение
Комментируйте без ограничений
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.