Внедрять или не внедрять. Развеиваем главные мифы о SRE
Site Reliability Engineering (SRE) пришел в компании, чтобы прорабатывать вопросы надежности целиком всей системы без разделения на отдельные зоны ответственности, как это было при работе сисадминов и программистов до появления DevOps’ов. Однако роль SRE-инженера, которую представил Google, каждый стал трактовать по-своему. Кто-то делал все строго по книге, а кто-то добавил в работу и свое личное видение.
Со временем обязанности SRE в компаниях, особенно на российском рынке, стали отличаться друг от друга. Вместе с тем появились сопутствующие вопросов о внедрении, обучении сотрудников, применении тех или иных инструментов и тд.
В этой статье мы собрали самые часто встречаемые мифы и вопросы о внедрении SRE и обучении его инструментам. Ответить на них нам помог Максим Гусев, Tech Lead SRE, на счету которого тысячи выстроенных пайплайнов CI/CD и более 100 инсталляций Kubernetes в продакшен.
SRE — пустая трата денег для бизнеса
Чтобы понять, нужны ли вам практики SRE, достаточно взглянуть на ваш бизнес. Если компания делает готовые решения, а клиент уже самостоятельно их разворачивает — SRE может и не понадобится. Если же компания предоставляет свой продукт напрямую клиенту, ей в какой-то момент придется задуматься о доступности, отказоустойчивости и об улучшении клиентского сервиса.
Количество клиентов рано или поздно начнет повышаться, а чем их больше, тем выше вероятность получения ошибок системы. Например, есть маленький учебный центр с лендингом и личным кабинетом, где лежат видеоуроки. Сервера прекрасно выдерживают 100 учеников, поэтому поводов для беспокойства нет. В какой-то момент по сарафанному радио пришли еще 500 человек. Тут и начались первые жалобы на задержки в роликах, проблемы со звуком, загрузкой и др. Разочарованные пользователи уходят на поиски альтернативы, а компания получает негативные отзывы и снижение прибыли.
Чтобы подобного сценария не случилось, нужен технический специалист, который будет смотреть наперед и общаться с бизнесом. SRE-инженер, рекомендовал бы закупить сервера с запасом. Тогда появится уверенность, что при первичном пике клиентов все не рухнет.
В каких компаниях требуется SRE?
SRE-нужен любой площадке, где клиент взаимодействует с бэкендом через фронтенд. Наиболее подходящей отрасли нет, потому что стабильность важна даже для самого маленького маркетплейса.
Мы выделили ряд отраслей, где данные с «зелеными графиками» необходимо обрабатывать на лету:
Онлайн игры
Крупный ритейл
Каршеринг
Поисковики
Стриминговые платформы
Финтех
Сервисы бронирования
Что компания получит от внедрения SRE?
Мы уже говорили о том, что практики SRE можно внедрять на разных этапах развития проекта. При внедрении инструментов SRE на ранних стадиях можно избежать проблем с системой в будущем. Если компания уже выкатилась в продакшн, идут продажи, с сервисом взаимодействуют люди, то в первую очередь SRE позволит улучшить клиентский сервис.
Когда проект запущен и работает без серьезных инцидентов, с помощью инструментов SRE можно собрать первичные проблемы, агрегировать их и исправить. Чем удобнее клиентам будет пользоваться сервисом, тем лучше заработает сарафанное радио.
Если в системе есть серьезные проблемы, то инструменты SRE позволят повысить доступность с помощью инженерного подхода. Также правильная работа команды позволит избежать крупных инцидентов в будущем.
С SRE бизнес начнет быстрее развиваться
Сказать, что с появлением SRE дела бизнеса сразу пойдут в гору — нельзя. Правильнее сказать, что с помощью этих практик у компании меньше шансов получить проблемы в процессе своего развития. Так, хорошая отказоустойчивость в какой-то момент может спасти от отвала сервиса и потери прибыли.
Независимо от своего возраста и размера бизнес хочет работать стабильно и получать хорошие отзывы пользователей. Проще все делать правильно с самого начала, потому что переучивать команду куда сложнее и дороже.
В компании уже есть SRE, что еще может дать обучение?
Есть люди или команды, которые стремятся регулярно прокачивать свои знания и навыки. Мы уже писали, что в каждой компании SRE внедряется разными путями. Кто-то следует всем инструкциям из книги, а где-то просто переименовали сисадмина в SRE-инженера.
Второй случай особо распространен на российском рынке. На обучении есть возможность «откалибровать» представление о правильном SRE, разобрать конкретные кейсы, проконсультироваться со специалистами, отработать внутренние регламенты на непродовом сервисе.
Если у компании уже есть SRE отдел, но проблемы с надежностью остались, эксперты помогут на практике решить проблему и наладить командную работу.
В чем профит человеку пойти учиться на SRE?
Пойти учиться на SRE с нуля нельзя, так как нужен бэкграунд в айти. Профит в первую очередь в повышении квалификации, а зачастую и зарплаты. На российском рынке SRE путают с инженером эксплуатации.
В истинном же варианте SRE в первую очередь разработчик, хорошо знающий инфраструктуру сервиса. В последние годы все больше компаний хотят на ранних этапах внедрять правильный SRE подход, поэтому им нужны люди с представлением об истинных задачах SRE-инженера.
А куда расти из SRE?
Градации очень размыты в зависимости от места работы. Для начала SRE-специалисту можно вырасти в SRE-лида. Обычно в крупных компаниях SRE-инженер после внедрения инструментов и доведения отказоустойчивости до хороших показателей переходит на позицию тимлида. Однако для этого нужно понимать принципы управления командой и менеджерские обязанности.
Еще один путь развития — техлид. Он распространяет инструменты и практики на всю компанию и при этом мониторит, чтобы все стабильно работало. Но и для этого потребуется время и опыт.
У меня нет команды
Некоторые специалисты приходят, чтобы самостоятельно разобраться в Site Reliability Engineering. Например, у человека есть бэкграунд инженера, он посмотрел, что SRE перспективное направление и купил курс для повышения собственных скиллов.
Другой случай, когда разработчик в компании понимает, что пора внедрять практики SRE. Он пошел к руководству и объяснил, что скоро будет недобор по ресурсам и могут начаться проблемы. Запросил бюджет, выучился и вернулся уже с рекомендациями, как действовать дальше. Бывает и так, что подобная инициатива исходит от руководства.
Обычный человек тоже может захотеть прослушать курс, поработать с новыми инструментами и получить сертификат. У всех в данном случае разные мотивы.
У нас в компании нет столько людей
Когда слишком маленькая команда, можно брать весьма широкого специалиста, который в зависимости от потребностей выполняет те или иные задачи. Например, есть архитектурные проблемы, и он смотрит на них со стороны архитектора. Когда доходит время до автоматизации и развития бизнес разработки, включается DevOps. При разговоре об отказоустойчивости специалист включает практики SRE.
Маленькой компании такой человек будет нужен, чтобы как минимум смотреть наперед. Тогда не получится так, что через пару лет понадобится внедрять новые вещи, а система и команда к этому не готова.
Также можно совмещать работу DevOps«а и SRE-инженера. Усидеть на двух стульях будет сложно, однако в некоторых компаниях существует подобная практика. Успешно совмещать получится у людей с большим опытом при условии, что практики DevOps в компании успешно внедрены и требуют лишь поддержки.
Почему обучение стоит дорого?
Учиться дорого, потому что это чужие знания, которые были кем-то добыты не за пару дней. Информацию сформировали и подали в правильном виде за короткий срок. Из чего же складывается цена? Процитируем ответ Максима Гусева:
«То, что проходится на интенсиве за три дня, я, например, полтора года сам учил. При этом совершал очень много ошибок, читал книги, когда их еще не было на русском языке. Чем легче процесс обучения, тем он дороже.
Весь материал можно найти бесплатно. Например, скачать в интернете книжку Google или посмотреть бесплатные курсы на YouTube. При этом потеряется главная ценность обучения — не будет возможности спросить. Там, где я преподавал, на вопрос «А почему так дорого?», я отвечал, что на курсе учащийся взаимодействует со специалистом и может прийти к нему с любым вопросом. Все это время, а его может и не быть. Вдруг вам нужно быстро во всем разобраться и срочно внедрить SRE.
Вторая статья расходов — это стенды, на которых проходит обучение. Развернуть для всех Kubernetes — это тоже время и расходы. Самому разворачивать их долго, возможно придется гуглить. Плюс нужно покупать сервера».
Преподаватели в Слёрм — тимлиды и директора российских и иностранных IT-компаний. Они приходят на три полных дня и полностью включены в процессы студентов. Также они предварительно готовят материал для обучения и практические задания. Учащихся же ждет не просто практика на стенде, где поднято определенное окружение. Их ждет отдельное приложение и самописная система генерации нагрузки.
7–9 октября 2022 пройдет уже 5-й интенсив SRE: data-driven подход к управлению надежностью систем.
На интенсиве вы:
узнаете, как снизить ущерб от отказов в будущем;
внедрите правки прямо в прод;
узнаете, как решать конкретные проблемы, связанные с надежностью сервиса;
поймете, какие метрики собирать и как это делать правильно;
научитесь быстро поднимать продакшн силами команды.
Вы получаете уникальные практические знания, на которые наши эксперты потратили годы. Можете посчитать, сколько времени потребуется специалисту, чтобы изучить технологии, например, Canary Deploy, провести первые эксперименты и внедрить их с учетом стоимости часа его работы. У нас он потрогает это решение руками, получит пример готового кода и сможет внедрить его в продакшене.
Для команд от 5 человек у нас действуют особые условия участия — 70 000 Р за 1 сотрудника, вместо 90 000 Р.
Узнать подробнее: https://slurm.club/3C3GP0q
