Лучшие DevOps практики и кейсы

Зачем мне нужны консультанты, если у меня уже есть DevOps?

К сожалению, наличие DevOps-инженера не гарантирует полного отсутствия проблем в этой сфере. Очень часто у людей может замыливаться взгляд, или они могут не иметь возможности выбрать правильные инструменты, или же не иметь понимания как решить эту проблему эффективнее для бизнеса, а не только предоставить техническое решение.

Зачем нужен DevOps

Основные причины:
  • Автоматизировать деплой
  • Сделать fault-tolerance cloud систему с автоматическим масштабированием
  • Избежать случаев неработы сервисы (даунтаймы)
  • Отсутствие дыр в безопасности
  • Администрация локальных и облачных серверов
  • Повысить качество кода разрабатываемого решения

Однако, Ваш DevOps можете выполнять работу не самым лучшим образом, чаще всего нам встречались такие проблемы:
  • Неиспользование новых технологий: деплой руками и на shell скриптах, Вы не понимаете у нас особый случай!
  • Использование новых технологий без необходимости будем как Google, для одного микросервера поднимем Kubernetes
  • Слабое понимание System Design и важности элементов: зачем нам CloudFront, сайт же летает, и неважно как он работает на другом континенте!
  • Отказ от использования облачных решений: нет, они очень дорогие, мы лучше поставим сервер здесь и я буду им заниматься (все свое рабочое время), зато не отдаем деньги непонятно за что
Продолжать можно до бесконечности, как правило, отличие консультанта и наемного работника в том, что он не всегда может быть заинтересован в построении наилучшей архитектуре и выборе подходящей технологии. 

Как работает консультант



DevOps консультант, как правило имеет обширный опыт работы в DevOps и видел много плохих и хороших решений. Независимо от модели оплата консультант заинтересован в помощи бизнесу, потому что от этого зависит оплата его работы. Наемному же сотруднику зачастую все равно на это.
Таким образом консультант фокусируется на решении как технических, так и бизнес проблем, учитывая бизнес-требования, сложность внедрения, время и прочие затраты. Консультант может выполнять задачи как самостоятельно, так и работать вместе с Dev и DevOps командами, беря на себя такие обязанности: ставить цели, помогать с выбором инструментов, объяснять свои решения, и делится своим опытом.
Нанимая консультанта Вы не нанимаете очередного наемного сотрудника (пару рук), а нанимаете компетентного специалиста для решения Вашей задачи(получая по сути партнера). Поэтому нету необходимости нести затраты на HR, а Вы знаете сколько стоит найм и сколько времени занимает закрыть DevOps вакансию. А во время поиска подходящих специалистов растут риски неисправности систем, оставленных без присмотра, все вышеперечисленные факторы стоит принимать во внимание.

Задачу решает наемный работник / консультант

Рассмотрим следующую ситуацию:
На новом проекте вам необходимо создать ПО состоящее из мобильного приложения, админ страницы, базы данных и инфраструктуры под это все. Это сложная система которая к тому же должна быть интегрирована с другими проектами заказчика. Задача DevOps-а в этом случае - дать максимально четкие рекомендации разработчикам о ключевых моментах которые стоит реализовать в приложении чтобы оно было масштабируемое и легко настраиваемое. К тому же стоит не забывать про построение инфраструктуры под проект, CI/CD процессов, безопасность и еще сотню вещей. Конечно же у всего цикла разработки есть определенный дедлайн.

Реакция наемного DevOps

Задачи по работе с разработчиками стают “костью в горле” или превращаются в бесконечный поток коммуникации, однако Вы занимались Cloud-задачами, которые решаются быстрее и хорошо знакомы Вам. Таким образом разработчики работали какое-то время не понимая ваших требований к приложению, например что оно должно быть stateless. Дев команда уже сделала первый билд, который, к сожалению, нельзя адекватно развернуть в продакшн реалиях. Вы отсрочили неизбежное, а давление все возрастает. Когда у Вас больше не осталось Cloud задач, а качественно решить поставленные задачи вы не можете, то наконец-то идете к Project Manager, чтобы высказать свои опасения на счет возможного провала презентации проекта. Вы чувствуете себя гораздо лучше, но потеряно много времени. 

Негативные последствия:
  • PM разочарован, что Вы так поздно пришли с проблемой, которую изначально знали
  • PM уважает Ваши технические навыки, но теперь ему в сжатые сроки необходимо будет придумать решение
  • PM не представляет себе как решить эту проблему

В худшем случае, придется перенести презентацию на неопределенный срок до нахождения решения, в результате чего компания может потерять свой статус и понизить уровень доверия стейкхолдеров.

Реакция DevOps консультанта

Анализируя Ваши задачи, Вы понимаете, что не видите подходящего решения задачам по развертыванию приложения, которое скоро напишут, поэтому Вы принимаете решение поговорить с менеджером проекта (PM). Хорошим правилом является приходить к PM с потенциальными решениями, а не только с проблемами. В течении встречи, Вы доносите проблему максимально доступным языком и объясняете ее влияние на презентацию продукта. Далее Вы представляете свои варианты решений, которые помогут презентации состоятся успешно, описывая их плюсы и минусы. Вместе с PM определяете дальнейший план действий рассматривая такие кейсы:
  • Дать четкие требования к приложению со стороны DevOps
  • Отложить запуск продукта по важным причинам
  • Отмена разработки продукта
  • Переработать с Dev командой особенности продукта

Подводя итоги, можно сделать вывод, что консультант имеет богатый технический опыт и хорошее понимание бизнеса, все эти навыки позволят Вам сэкономить деньги за счет его разумных решений, грамотной постановки целей и обмену опытом с Вашей командой. Также рекомендуем вам избавиться от заблуждений на счет работы консультанта с помощью этой статьи.

Если у Вас возникают сомнению на счет качества работы инфраструктуры - свяжитесь с нами чтобы детальнее обсудить задачи или же назаначьте звонок для получения аудита вашего кейса.
Статьи