Привет! Меня зовут Сергей, я занимаюсь направлением DevOps в KTS.
В прошлой статье мы рассмотрели, каким должен быть джуниор-DevOps-инженер. Сегодня пойдём чуть дальше, вспомним наш опыт и расскажем, какие ошибки могут мешать джуниорам перейти на грейд «мидл».
Что будет в статье:
Не привлекать других к решению проблем
В любой момент может возникнуть ситуация, когда нужен другой участник задачи. Это необязательно должен быть старший коллега по DevOps — возможно, нужен другой разработчик или вообще заказчик.
Например, в больших компаниях процесс получения сетевых доступов и других подобных вещей может быть достаточно долгим и сложным. Если джуниор-DevOps впервые сталкивается с задачей, требующей добавления подобных доступов, то общение с коллегами, которые уже проходили этот процесс, поможет в разы ускорить получение необходимого результата.
Ситуация: необходимо развернуть новый сервис. Он требует дополнительных конфигураций, настроек, инфраструктурных зависимостей. Запустить сервис с нуля часто тяжело — постоянно возникают новые ошибки, а по логам не всегда можно чётко понять, чего не хватило.
Правильное решение: Вместо того, чтобы долго копаться и пытаться запустить сервис самостоятельно — сходить к разработчикам, которые писали код и точно знают, как всё работает и что нужно для запуска. Можно даже ввести правило: «Если проблему не получается решить за полчаса, начинайте задавать вопросы».
Не менеджерить свою задачу
DevOps не создаёт продукт самостоятельно. Это профессия, которая оптимизирует и усиливает рабочие процессы других разработчиков по производству конечных сервисов, которыми кто-то пользуется. Поэтому все проблемы решаются только совместно с остальными участниками. И если DevOps-инженер не возьмёт на себя ответственность по коммуникации со всеми участниками своей части работы, то добиться хорошего и, главное, полезного результата будет крайне сложно.
Ситуация: нужно перевезти сервис из одной инфраструктуры в другую. Это большая задача, на которую вряд ли назначат одного DevOps-джуниора, но она хорошо подходит для иллюстрации этой ошибки. В налаживании инфраструктуры участвовало много людей. Задача девопсера — не прокрастинировать от того, что задача большая и сложная, а прийти ко всем, кто имеет или имел отношение к инфраструктуре и разработке сервиса и спросить, как всё устроено: какие есть зависимости у сервиса, с какими другими элементами структуры он взаимодействует?
Правильное решение: написать план по переезду, согласовать его со всеми участниками и договориться, как будет осуществляться переезд. Это твоя задача, поэтому пока задача не будет выполнена — нужно следить за процессом и пинговать всех участников, чтобы быть уверенным, что всё идёт по плану.
Перекладывать ответственность при разборе инцидентов
В работу и ответственность DevOps часто входит задача SRE (Site Reliability Engineering), разбор ошибок и инцидентов. Поэтому первое, о чём нужно думать — не «кто виноват в поломке», а «как заставить всё работать без перебоев?»
Ситуация: от сервиса приходят ошибки 500. DevOps-инженер видит в логах какой-нибудь exception, например KeyError. Если нет ничего похожего на ошибки сети и инфраструктуры и думает: «Это проблема логики сервиса, а не моя». Но проблемы с сервисом — в любом случае общие, и каждый участник заинтересован в их решении.
В теории возможна ситуация, что недоступность какого-то вспомогательного сервиса неправильно обработана в коде, в результате чего код падает где-то позже с довольно непрозрачной ошибкой.
Правильное решение:
вести инцидент от начала и до конца
найти корень проблемы: поставить задачу разработчикам на исправление обработки ошибки, проверить мониторинг упавшего сервиса
Главное, понимать: любые проблемы сервиса касаются всех.
Использовать временные решения вместо продуманных
При появлении проблемы всегда есть соблазн по-быстрому заткнуть её и забыть. Но такой ход мыслей ведёт к плохим последствиям. Во-первых, быстрое костыльное решение может в какой-то момент посыпаться. Если таких решений много, есть шанс, что все инженеры утонут в затыкании алертов и прочих проблем, а времени на развитие инфраструктуры не останется.
Ситуация: на сервере с Clickhouse место на диске подходит к концу. Быстрое временное решение — добавить места. И добавлять его каждый раз, когда закончится — тем самым увеличивая стоимость инфраструктуры.
Правильное решение: выяснить, почему место выросло, и устранить ключевую проблему. Например, в Clickhouse по дефолту некоторые логи пишутся прямо во внутренние таблицы. А в привычном всем месте в /var/log/ их будет немного. В итоге может быть ситуация, что большую часть диска занимают не данные сервиса, а логи Clickhouse, которые в таком объёме никому не нужны. Важно настроить правильную ротацию логов внутри системных таблиц и оставить только то, что действительно нужно.
Внедрять новые инструменты и не рассказывать об этом
Выше мы сказали, что DevOps оптимизирует и усиливает рабочие процессы других разработчиков. Для этого девопсеры автоматизируют тестирование, настраивают мониторинг и логи, оптимизируют хранение данных. Но ценность таких нововведений в том, чтобы не просто сделать, а чтобы остальные разработчики пользовались новым инструментом, оптимизируя работу.
Ситуация: DevOps-инженер настроил новые дашборды мониторинга, метрики и алерты. Но об этом знает только его команда, а разработчики не в курсе. Получается, что задача сделана, но польза в компанию не поступает.
Правильное решение: чтобы бизнес начал получать выгоду, девопсер должен организовать встречу, продемонстрировать результаты, а после — убедиться, что новые инструменты действительно используют. Возможно, даже сделать что-то за разработчиков, чтобы им было проще. Если недостаточно объяснить выгоду и правила использования, коллеги могут воспринимать новый инструмент как очередную задачу. Тогда, даже если он упрощает работу, разработчики будут откладывать его применение.
Не вникать в показатели эффективности
Чтобы понимать ценность своей работы, нужно знать: на какие показатели повлияет эта работа, зачем её делать? DevOps, как эксперты в области инфраструктуры, часто несут ответственность за определение собственных метрик и показателей, которые могут не пересекаться с метриками разработчиков и аналитиков.
Ситуация: есть задача настроить мониторинг сервиса. Можно сделать всё быстро и взять стандартный набор метрик, например, обычное использование ресурсов: процессор, память. Но работа с таким мониторингом будет малопродуктивна, если не узнать, на что нужно смотреть и к кому идти при появлении проблем. Та же разработка просто увидит высокое потребление CPU, но не сможет разобраться, почему оно возникает.
Правильное решение: разобраться, как работает сервис, какие метрики на самом деле действительно важны, построить правильные алерты, обсудить всё с разработкой и закрепить предыдущим пунктом — рассказать о новом мониторинге всем.
Не прогнозировать последствия
При любых деструктивных действиях есть опасность того, что сломается что-то важное. Поэтому девопсер должен относиться к своим сервисам с умеренной паранойей: всегда предполагать, что любое изменение инфраструктуры влияет на рабочие процессы.
Ситуация: все участники проекта — разработчики, заказчик — подтвердили, что можно отключать одну из виртуальных машин. DevOps «погасили» её, но, как оказалось, на машине были запущены другие важные сервисы, о которых все забыли. В итоге остановилось одно из окружений.
Правильное решение — любое деструктивное действие выполнять последовательно с чётким планом «наката» и «отката». Вместо того, чтобы делать деструктивное действие, можно всегда его сэмулировать. Например: вместо удаления виртуалки просто погасить её и понаблюдать за работой всех сервисов. Всегда спрашивайте себя: «К каким последствиям могут привести мои действия? Как всё вернуть обратно, если что-то пойдёт не так?»
Заключение
В этой мини-статье мы постарались разобраться, чем отличаются уверенно растущие DevOps-инженеры от тех, кто застрял в развитии.
Получается, что основная проблема — в софт-скилах: принятие ответственности, понимание смысла, коммуникации. Это не значит, что важно только это. Нужно много учиться и развивать технические навыки, но определённые вещи мешают развитию при любом уровне знаний в технологиях, и они связаны с софт-скилами. Потому что рост всегда связан с самостоятельностью и ответственностью, которую можно возложить на человека.
DevOps — профессия, усиливающая разработчиков и инфраструктуру. Поэтому и ценность от неё есть только тогда, когда помогаешь другим и понимаешь, как это делать.
Если вы работаете в DevOps, посмотрите, какие вакансии сейчас открыты у нас.
Если знаний пока недостаточно, но эта тема вам интересна, приходите учиться! Недавно мы открыли доступ к курсу «Деплой приложений в Kubernetes». Это курс для разработчиков, где мы рассмотрим самые важные концепции, необходимые для взаимодействия с кластерами Kubernetes, и научим применять эти знания на практике.
? Посмотреть подробнее, что будет в программе, можно на странице курса.
Другие статьи про DevOps для начинающих:
Другие статьи про DevOps для продолжающих:
