DaaS (DevOps as a Service), чего?!

На заре гибкой разработки все удивлялись насколько быстро и динамично могут разрабатываться и обновляться продукты. И это при том, что сроки по современным меркам были конские и растягивались на месяцы и года. У продуктов даже был шанс не устареть к моменту его релиза. У разработчиков закончить фичу, у админов заказать железо и ждать месяц, у тестировщиков вручную 100 раз все протестировать итд итп..

А что сейчас? Сейчас, вы заказываете разработку и, вполне возможно, через несколько месяцев ваш продукт, не смотря на то, что еще не выпущен — уже outdated. Более того, вы еще даже не подготовили площадку, на которой будет хоститься ваш уже устаревший нерелизнутый продукт. Вы не сделали до конца ни одной фичи, вы ее даже не видели — негде посмотреть. Да, проблема может быть слегка раздута и высосана из пальца, ведь всегда можно запустить ngrock с локальной рабочей станции для демки, а для mvp создать heroku app, в конце концов. А что если ваш продукт под HIPAA compliance, или PCI DSS — как это настраивать, показывать и проверять, как проводить аудит и тестировать? Добавим сюда масштабируемость как вертикальную, так и горизонтальную, помножим на высокую доступность, failover и непрерывные поставки, и в какой-то момент в проекте все опять упирается в опса, сисопса, девопса или инфраструктурного архитекта, или как эти люди сейчас называются. Точнее, в их наличие, и конечно же скиллы.

А нет! Все выше написанное не про вас, и вы уже заранее это предусмотрели — нашли и растите своего личного девопса. Правда он завален миллионом мелких задач и как-то не растет особо, или просто не хочет или не знает с чего начать. Наверное нужно искать второго, но что делать с ним, когда он станет не нужен? Честно сказать ему, что он нужен на два месяца, а пойдет ли? А что делать, если сейчас необходимо 5 фуллтайм админов(с разным уровнем и скиллами), а через месяц объем работы останется на одного парттайм? HR и рекрутинг в шоке.

В дооблачную эпоху в аналогичном шоке были и сами админы, когда при все ускоряющемся ритме приходилось “жонглировать” вычислительными ресурсами, думать наперед о том, что делать с излишками или, как быстро, хотя бы за неделю, восполнить недостатки. Сейчас все просто — есть облака, классы инстансов и автоскейлинг. Вы создаете эластичную инфраструктуру, в которой используется ровно столько ресурсов, сколько требуется в данный момент. Возможно ли такое с админами?

Мы в Mad Devs давно развиваем наш ОПСовый отдел, который во всех проектах MD участвует в полном составе. Сначала у кастомера поднимается бровь — а зачем так много людей, мне нужно всего 80 часов в месяц? Однако скоро все вопросы отпадают — клиент получает полную экспертизу MD, возможность масштабировать девопс ресурсы, в разы уменьшенный камазфактор, оптимальное использование часов — архитектору архитекторово, сеньору сеньорово, миддлу миддлово). В случае же нештатных ситуаций все ресурсы бросаются на решение проблемы. Вам также не нужно думать что делать с человеком, вы просто перестаете платить, если нет задач. С другой стороны, если помимо проектных задач, есть задачи по мониторингу и дежурствам, есть жесткие сроки реакций на инциденты, не важно — день это или ночь, одного опса вам точно не хватит, нужно содержать штат минимум из трех людей и платить всем фуллтайм. И напротив — в MD платя за одного фуллтайм опса вы получаете сервис опсов и/или SRE, который всегда онлайн и всегда в контексте.

Если подытожить:

• Какой бы не был нужен штат опсов, это теперь не ваша забота — вам не нужно искать или растить своих
• Также, вас не волнует, что делать с отпусками, праздниками или больничными
• В работах будет задействованы все опсы, которые есть в команде. Совместная работа участников команды, общая база знаний и документация, а так же следование парадигме infrastructure as a code исключают боль онбординга нового админа в проект
• В случае инцидентов или срочных работ мобилизуется необходимое число инженеров, значительно ускоряя достижение результата
• Аналогично и в случае уменьшения нагрузки. Вы получаете гибкость ресурсов
• Нет единой точки отказа и единого носителя важной информации
• Оптимально используются скиллы и оплата за них

А что инженерам хорошего от такого подхода?

• Быстрый рост скиллов, так как много проектов с разными кейсами, инфраструктурами и задачами
• Нет гниения в одном проекте (пусть даже самом лучшем и интересном), но который никому не передать
• Постоянно новые проекты, новые задачи и челленджи и конечно же рост ЗП