Как и обещали, продолжаем цикл постов о DevOps (ага, в пятницу вечером, издеваемся над вашим мозгом 😅 но раз уж обещали) Сегодня будет про DevOps и SRE - как они связаны с системным администрированием. Чем в команде эксплуатации занимается SRE инженер? Чем он отличается от роли DevOps инженера или это одна и та же роль? SRE (Site Reliability Engineer) - действительно, так могут называть и DevOps специалистов, но различия все же есть, как и есть отдельные роли (особенно в крупных компаниях, высоконагруженных проектах). Так же есть в разных компаниях целые отделы: отдельно команды Devops, отдельно SRE, отдельно админы. Так что важно разницу понимать. SRE - это DevOps наоборот, топовый разработчик который обладает всеми навыками разработчика и DevOps-a. Пока путанно, дабы стало понятнее, обратимся к истории, там как всегда все ответы. Ввел в обиход it терминологии эту роль Google. В 2016 году Google выпустила книгу о SRE (Site Reliability Engineering) и рассказала миру кто это такие и зачем они нужны и важны. С чем столкнулся и что решил сам Google? Примерно в аналогичное время становления Devops практик (более 10 лет назад) мир активно обратился к цифре, популярность it продуктов росла кратно, количество пользователей it продуктов росло быстрыми темпами (вспомните когда вы перестали совершать офлайн походы в магазины и стали многое заказывать на дом, подумайте - сколько нас таких). Мы, обычные люди, стали отправлять свои запросы в интернет приложения, т.е. мы стали отправлять в разы больше своих запросов на сервера разных it продуктов. Как компании справиться с наплывом новых пользователей в плюс 10 миллионов? Первый понятный путь - увеличивать мощность существующего сервера, чтобы никто не страдал от нагрузки на продукт и по прежнему быстро получал ответы на свои запросы. Как это ранее делал Google (и не только он) - увеличивал мощность продукта в рамках увеличения мощности одного сервера, администраторы шли в Data центры (прямо здания для размещения серверного и сетевого оборудования), ставили в нем больше процессоров, дополнительные сетевые диски, добавляли оперативной памяти и прочее, и в итоге, получался один, но более мощный сервер. Google понял, что это очень дорого и гораздо дешевле брать миллиарды маломощных обычных серверов и объединить их в одну сеть (которая образует кластер), при этом комплексная мощность таких кластеров будет выше. А чтобы усилить сервер, добавляем еще 200 обычных серверов в кластер и мощность увеличилась. Стандартные системные администраторы с такими кластерами не работали и не знали как обслуживать такое количество серверов. К примеру, у системного администратора их было 30 - они руками их проверяли и правили. Когда их не 30, а миллион - ручками это делать трудно, нужна армия администраторов с тонной ручной работы. И Google понял, что нужны программисты, которые напишут код для управления кластерами серверов, это и есть SRE инженеры. Задача SRE свести к минимуму работу программиста в направлении системного администрирования. Но вы зададите законный вопрос - а где же разница между DevOps-ом и SRE? Ответим, на простом (держим, правда, в голове, что разные компании по разному могут называть позиции и создавать гибриды). DevOps - новое поколение администраторов, которые организуют и автоматизируют инфраструктуру для продуктов компании. SRE - новое поколение администраторов, которые организуют и автоматизируют ОГРОМНЫЕ инфраструктуры для продуктов компании Важное различие - масштаб инфраструктуры. На западном рынке разделение на DevOps и SRE более четкое. На российском пока можно встретить разные гибриды. А в следующем тематическом посте разберемся какие еще инструменты или обязанности позволят нам, рекрутерам понять, что кандидат знает и умеет применять Devops практики. Оставайтесь с нами 💚 — Оглавление канала - сбор всех полезных тем и постов канала по рубрикам Все о курсе IT-рекрутер - много практического о курсе с видео-примерами и ссылками