Меня зовут Дмитрий Масленников, и я руковожу Центром надёжности информационных систем в Тинькофф. Недавно я выступал на вебинаре Слёрма «Особенности SRE в России». В поддержку своего курса по «SRE: внедряем DevOps от Google» Слёрм собирает интересные кейсы внедрения SRE в российских компаниях. Я рассказал, как устроена наша экосистема SRE, зачем мы используем самописные сервисы, почему в SRE должна работать инженерная элита и как примкнуть к этой элите за один день. А теперь делюсь этим здесь.
Надежность (reliability) программного продукта всегда является одним из приоритетов компании. Особенно это актуально для ПО, превратившегося в ежедневный инструмент для своих пользователей. Они рассчитывают на заявленный функционал, поэтому любая невозможность его использования подрывает доверие, а следовательно, и желание им пользоваться.
В этой статье пойдет речь о главных инструментах Site Reliability Engineering (SRE) и о том, как они влияют на повышение надежности систем.
Site Reliability Engineering (SRE) пришел в компании, чтобы прорабатывать вопросы надежности целиком всей системы без разделения на отдельные зоны ответственности, как это было при работе сисадминов и программистов до появления DevOps'ов. Однако роль SRE-инженера, которую представил Google, каждый стал трактовать по-своему. Кто-то делал все строго по книге, а кто-то добавил в работу и свое личное видение.
Со временем обязанности SRE в компаниях, особенно на российском рынке, стали отличаться друг от друга. Вместе с тем появились сопутствующие вопросов о внедрении, обучении сотрудников, применении тех или иных инструментов и тд.
В этой статье мы собрали самые часто встречаемые мифы и вопросы о внедрении SRE и обучении его инструментам. Ответить на них нам помог Максим Гусев, Tech Lead SRE, на счету которого тысячи выстроенных пайплайнов CI/CD и более 100 инсталляций Kubernetes в продакшен.
Установка SLO (Service Level Objective, целевых уровней обслуживания) — одна из базовых задач SRE. По этим показателям удобно оценивать надежность службы. Противоположность SLO — бюджет на ошибки, то есть какой уровень ненадежности считать допустимым. Когда мы определим эти показатели и установим SLO, нужно проверить их реалистичность с учетом архитектуры приложения и рабочих практик. Мы точно сможем их достичь? На что, скорее всего, уйдёт наш бюджет на ошибки?
SRE-инженеры из Google отвечают на эти вопросы при выпуске нового сервиса, когда проводят PRR (Production Readiness Review — проверку готовности продукта). Мы анализируем риски не для того, чтобы изменить SLO. Скорее, мы хотим приоритизировать риски для сервиса, чтобы прикинуть, сможем ли мы достичь наших SLO с учетом изменений сервиса или без них. Кроме того, с помощью анализа мы определим самые важные риски. Определяя и снижая риски, мы повышаем надежность сервиса.
Прежде чем оценить и приоритизировать риски, нужно составить полный список того, чего стоит опасаться. В этой статье приводятся рекомендации для команд, которые будут определять потенциальные риски для приложения. Определив риски, вы сможете проанализировать их и расставить приоритеты.
Привет! Мы решили собрать для вас все статьи о Site reliability engineering (SRE) в одном месте.
В материалах ниже вы найдете информацию о внедрении SRE, вариантах применения отдельных практик, а также полезные кейсы от нескольких компаний.
Эпоха монолитных приложений почти прошла. Современные системы разделены на множество компонентов. Даже в самом простом приложении может быть много микросервисов, а у тех есть свои составляющие, например база данных, так что число элементов в системе растёт в геометрической прогрессии.
Чем качественнее наблюдение, тем меньше багов. А ещё можно вовремя находить узкие места и тратить меньше времени на обслуживание системы. В этой статье мы поговорим о наблюдаемости и её главных инструментах.
Замечали, как часто в ИТ-отрасли появляется модное словечко, и тут же все начинают вставлять его в описание своих продуктов, чтобы привлечь побольше внимания?
Сейчас у нас в тренде observability (наблюдаемость), и многие вендоры уже берут его на вооружение.
Что такое observability? Просто навороченная версия мониторинга? Быстрее, выше, сильнее, настоящий Чак Норрис среди DevOps-инструментов! Так и хочется прикупить себе наблюдаемости, правда?
Давайте не будем поддаваться всеобщему ажиотажу и попробуем разобраться, что это такое и откуда вся шумиха.
Привет, Хабр! Меня зовут Ира, я SRE в команде Samokat.tech. В этом посте хочу поделиться подходом в тестировании, которым мы пользуемся сами. Если вам при подготовке тестов часто приходится писать похожие друг на друга как две капли воды заглушки (или, как их ещё называют, «моки»), а затем заботиться о том, чтобы их развернуть, то вам может понравиться наше решение. Освободившись от части рутинных забот, вы можете уделить больше времени чему-то более важному.
Разношёрстные и хаотично развёрнутые в окружении заглушки – дорогие и неэффективные. В каждой отдельной заглушке разбирается в лучшем случае только одна команда, чаще только один человек. Со временем при накоплении критической массы они становятся фактически неподдерживаемыми.
Такие заглушки редко переиспользуются и что важнее, никто ими не делится, так как они либо тривиальны, либо написаны не самым лучшим способом (могут оказаться слишком сложными или неоптимальными).
Сложно представить тестировщика в роли доброго самаритянина, раздающего коллегам свои заглушки. Его к этому вряд ли что-то мотивирует, да и работы у него всегда прилично. Некогда отвлекаться! Так, давайте разгрузим немного нашего трудягу.
Книга Google о SRE, статьи экспертов, документация и обучающие курсы дают исчерпывающие знания о том, как в идеале должен работать SRE в компаниях. Правда, ключевое здесь – «в идеале». Работа с метриками и управление инцидентами в командах может сильно различаться по ряду причин: количество людей в команде, скорость выкатки нового функционала, число микросервисов, распределение компетенций и тд.
Когда переходишь от теории к реалиям жизни непременно возникают тупики и вопросы: как внедрить бюджет ошибок, кто за него будет ответственен, как договориться с разработкой, должны ли SRE-инженеры лезть в код при инцидентах и многое другое. В этой статье мы поговорим о выстраивании рабочего процесса на старте, когда вам нужно выставить первый SLO, рассчитать бюджет ошибок и мирно обо всем договориться с командой разработки и бизнесом.
В этой статье мы поговорим об использовании Chaos Mesh — опенсорс-фреймворка для хаос-инжиниринга в Kubernetes. Все развёртывания из этой статьи доступны на GitLab. Клонируйте репозиторий и продолжайте читать.
22 сентября Слёрм запускает новый практический курс по внедрению редких для российского рынка инструментов SRE для повышения стабильности системы. В программу интенсивов вошли темы, которые принципиально отличают работу SRE-инженеров от практик DevOps.
Поговорим про: Observability, Reliability architecture patterns, Proactive reliability testing, Chaos Engineering, Intelligent delivery of changes, Incident management.
SRE подход – это методология работы с цифровыми продуктами. Её задача – через улучшение процессов и автоматизацию уменьшить время простоя и количество ошибок сервиса, делая бизнес более предсказуемым и устойчивым.
С 7 по 9 октября Слёрм проведет пятый онлайн-интенсив SRE: data-driven подход к управлению надёжностью систем. На нашем интенсиве вы сможете получить представление, чем занимаются SRE-инженеры в реальности и с какими вызовами сталкиваются. Для этого на интенсиве будет немного теории, опытные спикеры и специально написанное приложение для покупки билетов в кинотеатрах, где вы отработаете практические кейсы.
В этой статье мы рассказываем, какие задачи вы научитесь решать за три дня обучения, и как может улучшиться работа вашей системы после.
С 6 по 27 декабря пройдет первый поток курса SRE: data-driven подход к управлению надёжностью систем. Вместо трехдневного интенсива вас ждут полноценные три недели обучения по сниженной цене и с большим количеством практики. Курс составлен по принципу полного погружения в среду, чтобы студенты не просто изучали теорию и смотрели видеоуроки, а могли сами потрогать различные инструменты и поработать в команде.
Рассказываем, какие задачи вы научитесь решать, и как может улучшиться работа вашей системы после.
Какой нужен бэкграунд и можно ли стать SRE без опыта в IT? А если опыт есть, с чего лучше начать? Всех, кто хочет понять, подходит ли вам профессия SRE и как правильно в нее перейти из devops, разработки или системного администрирования, мы приглашаем на наш бесплатный вебинар «Карьера SRE-инженера» 9 февраля в 19.00 по мск.
28 февраля стартует новый поток обновленного курса «Site Reliability Engineering: data- подход к управлению надежности систем». Будем учиться три недели, за которые вы на практике разберете современные практики SRE и инструменты для повышения доступности и надежности ваших IT-систем, включая мониторинг, автоматизацию, оптимизацию процессов и управление инцидентами.
Чтобы после курса вы смогли применить знания на реальных проектах, мы выстроили обучение вокруг специально разработанного приложения по продаже билетов для кинотеатров. На нем вы будете решать реальные задачи связанные с надежностью. В общей сложности вы проведете в роли SRE-инженера более 24 часов.
14 марта стартует курс «SRE: Observability» для всех, кто хочет научиться агрегировать SLO/SLI в одну или несколько высокоуровневых метрик. Рассказываем, почему observability – это то, с чего нужно начать в первую очередь, если ваша задача повысить надежность системы.
Все хотят приложения без даунтаймов и жалоб пользователей на постоянные простои, но не все понимают с чего начать и как подойти к вопросу системно. Обеспечить высокую доступность, надежность и производительность своих сервисов поможет культура SRE. Возможно, в вашей компании уже используются ее отдельные инструменты.
Мы приготовили для вас самотестирование. Пройдитесь хорошенько по всем пунктам, можете даже подключить к обсуждению коллег. По итогу определите, на каком уровне находится культура SRE в вашей компании, чего ей не хватает и нужно ли вам идти на обучение.
SRE-инженер помогает обеспечить бесперебойную работу высоконагруженных сервисов. Ему необходимо разбираться в инфраструктуре и конфигурации серверов, быстро читать логи. Он также часто участвует в разработке продукта и должен хорошо его знать, чтобы уметь поправить баг самостоятельно.
Мониторинг в Grafana дает множество преимуществ: визуализацию метрик, создание и настройка дашбордов, интеграцию с различными источниками данных, автоматизацию мониторинга, оптимизацию производительности и не только.
Всех, кто хочет обеспечить, контролировать и поддерживать надежную работу сервиса, мы приглашаем на наш курс «Мониторинг в Grafana», где вы научитесь работать со связкой Prometheus+Grafana, разбираться в работе системы и читать созданные графики.