Развитие технологий неизбежно вело к многочисленным изменениям. Со временем появились новые сервисы, новые специальности, и все больше давно существующих сфер стали в той или иной степени зависеть от ИТ. Такое разнообразие дарит много возможностей, но в тоже время может привести к замедлению отлаженных схем работы. Новые технологии требуют большего понимания, более грамотного взаимодействия всех структур, а то и вовсе кардинально иного подхода к существующим процессам. Наиболее яркий и актуальный пример ― Облачные сервисы (обычные, гибридные и мультиоблачные).
Чтобы поспевать за всеми изменениями и превращать их в реальную выгоду, стали появляться различные <Name>Ops-практики ― своды рекомендаций и опробованных приемов построения более эффективных процессов разработки и доставки программных продуктов за счет коллаборации разных команд. На сегодняшний день таких Ops-ов существует уже более десятка, и далеко не все понимают их смысл. Рассмотрим, что скрывают за собой основные термины, и какую конкретную пользу от применения этих практик можно извлекать уже сейчас.
DevOps
Это одна из первых практик этой категории, которая «подарила» основной принцип и правила нейминга остальным. Она возникла наиболее естественным образом как логичный способ значительно ускорить разработку, не потеряв при этом в качестве.
Суть метода отображает его название, которое является сокращением от двух смежных, но разных направлений ― Developers и (IT) Operations. То есть смысл заключается в более тесном взаимодействии разработчиков и команды operations. Последних могут называть отделом обслуживания, эксплуатации или специалистами инфраструктуры, но в целом термин подразумевает некий внутренний сервис, который ИТ-департамент оказывает всей компании (обычно он сводится к поддержанию работы серверов).
Чтобы ускорить цикл разработки (написание, тестирование, развертывание и т.д.) нужно иметь возможность быстро работать с инфраструктурой. То есть тем, что будет окружать программу после ее запуска. Для этого разработчики постепенно стали углублять знания в этой области и выходить за рамки своих ключевых обязанностей, занимаясь в том числе инфраструктурой. Поскольку подход, при котором этими вещами раздельно занимались разные специалисты, замедлял процессы.
Со временем акцент методологии DevOps сместился в сторону отдела Operations, который стал больше понимать в программировании и готовить инфраструктуру таким образом, чтобы она была удобной для разработки.
SecOps
Этот термин появился относительно давно, однако изначально обозначал управление безопасностью в общем. Позже сформировалась практика, подразумевающая именно коллаборацию Security и Operations, по аналогии с DevOps. Это направление стремится к сотрудничеству между ИБ и Operations, объединяя инструменты, процессы и технологии для обеспечения безопасности компании при одновременном снижении рисков.
Происходит это за счет повышения осведомленности сотрудников о том, как вопросы защищенности влияют на бизнес-процессы. Основные принципы интегрируются в существующую модель работы, и operations-специалисты отвечают не только за корректное функционирование инфраструктуры, но и ее безопасность.
Таким образом улучшается про-активное понимание рисков, что позволяет объединенной команде эффективнее предотвращать, обнаруживать и реагировать на угрозы.
Следующим этапом развития стала методология DevSecOps, совмещающая все три направления. К первым двум практикам добавляется взаимодействие Security и Developers, то есть принципы безопасности применяются уже на ранних этапах разработки. Программисты следят, чтобы код не содержал уязвимостей, ИБ-специалисты могут протестировать ПО до его запуска. В результате повышается прозрачность процессов, скорость поставки ПО и его защищенность.
FinOps
FinOps появился более осознанно как способ оптимизировать использование облачных решений. При необходимости эта практика может применяться и для приватных инфраструктур, однако появилась она именно в силу особенностей Облака как ответ на его вызовы.
Во-первых, оно может быть всегда доступно для конечных пользователей. Во-вторых, облачная инфраструктура не ограничивается физическими устройствами, а потому может многократно масштабироваться до необходимых размеров. В-третьих, более гибкая система оплаты: компании не покупают инфраструктуру наперед, а платят ровно за то время, которое используют (вплоть до минуты) облачные ресурсы.
Однако, как всегда бывает с любыми технологиями, вместе с их плюсами появляются и новые минусы. В случае с Облаком ― это сильное размывание границ расходов. Меняется принцип закупки инфраструктуры ― разработчики тратят средства непосредственно во время работы (вне поля зрения финансовых специалистов), и предоставляют счет постфактум. У сотрудников финансового отдела или держателей бюджета возникает вопрос ― каким образом это учитывать и, что важнее, прогнозировать.
На решение этой проблемы и нацелен FinOps. По сути, FinOps ― это новое название появившегося гораздо ранее направления Cloud Cost Management (управление расходами на облако). Но этот термин, как и другие, рассматриваемые нами, подчеркивает взаимодействие разных команд внутри компании ― Finance и Operations. Следование основным принципам практики повышает прозрачность расходов для обоих отделов, устанавливает ответственность для каждого, кто работает с Облаком, помогает оптимизировать использование ресурсов и в итоге превращает переменную модель стоимости в преимущество. Хотим подчеркнуть, что FinOps не стоит рассматривать исключительно как инструмент экономии расходов на Облако. Наоборот, он помогает тратить правильно ― то есть при таких же (или больших) вложениях извлекать максимум бизнес-выгоды.
CloudOps
Это самый молодой и наиболее искусственный термин. В отличие от остальных практик, CloudOps не ставит во главу угла коллаборацию разных структур. В целом эта практика подразумевает под собой устоявшиеся принципы работы с инфраструктурой, будь то приватной или облачной, но делает акцент на особенностях Облака – его динамичности, доступности и неограниченности. При этом направление частично включает в себя полный набор административных функций ― настройку, развертывание и оптимизацию ИТ-сервисов, поддержание их работоспособности, а также контроль за бюджетом и обеспечением безопасности.
Как быстро внедрить <Name>Ops
Никак. Важно понимать, что все вышеперечисленное ― это не сервисы, которые можно единожды ввести в эксплуатацию и пожинать плоды. Ops-ы нужно практиковать. За набирающими популярность терминами скрывается набор предписаний и рекомендаций о том, как повышать эффективность того или иного процесса ― разработки, управления стоимостью и т.д. Необходимо брать простые принципы и по возможности интегрировать их в существующую работу, постепенно добавляя более сложные, и взращивая в компании соответствующую культуру.
Тем не менее, более быстрый способ получить плюсы от использования тех или иных Ops-методологий существует. Эту задачу могут выполнить различные сервисы, работа которых строится вокруг реализации описанных рекомендаций. Яркий пример ― российская платформа решений для управления мультиоблаком Cloudmaster*.
*Этот инструмент позволяет централизованно управлять облачной и приватной инфраструктурой, анализировать данные и оптимизировать затраты. При этом вся функциональность базируется на принципах FinOps и CloudOps.
FinOps-решение Coster предоставляет всю информацию о имеющихся мульти-облачных ресурсах и расходах в едином окне, позволяет управлять ими в несколько кликов и регулярно предлагает пути оптимизации, используя уникальный алгоритм.
CloudOps-решение Clouder снижает простои и помогает эффективнее распределять вычислительные мощности, а также упрощает доступ пользователям к ВМ, сохраняя ответственность.
Платформа предоставляет максимальную прозрачность вне зависимости от типа Облака и количества подписок.
Кроме того, команда Cloudmaster активно поддерживает тренд на внедрение FinOps-практик среди компаний на рынке РФ и отдельно предлагает диагностику ИТ-инфраструктуры, проводимую сертифицированным специалистом по FinOps.
Получайте новые статьи моментально в Telegram по ссылке: https://t.me/sldonline_bot.
