Привет! Меня зовут Сергей, я занимаюсь направлением 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 для продолжающих:
Комментарии (12)
budnikovsergey
04.12.2023 11:22"девопсер" это корректный термин?
SWATOPLUS
04.12.2023 11:22+1А кто такой девопс? Объясните мне наконец. Что девопс должен уметь? В моей картине мира, девопс это разработчик, который помимо разработки веб-сервисов ещё умеет заниматься развертыванием. В частности настройкой CI/CD, облачных платформам, докеров с кубернетусами. Так же этот разработчик должен знать нюансы технологий в духе чем отличается RabbitMQ от Kafka и как этот все настраивать, что бы выдерживало нагрузку, как и за чем нужно следить, что бы продакшн не лег.
То есть это архитектор или техлид проекта, человек с большим опытом и знанием технологий к которому сложно применить слово джуниор.
Но я почему-то вижу курсы которые сделают тебя девопсом после курса по питону. Видимо Джуниор девопс, это тот кто пишет скрипты на питоне и что-то там автоматизирует фул-тайм.
Так если Джун скрипты пишет, может оставим его в покое. Дяди посерьёзнее это поревьювят и если что-то не так -- исправят.
saboteur_kiev
04.12.2023 11:22+1Девопс это не разработчик.
Это сисадмин, который отвечает за инфраструктуру компании, в которой идет разработка продукта. Следовательно его инфраструктура включает не локальную сеть компании и 1с у бухгалтера, а сервера, где происходит сборка, тестирование, разворачивание и поддержка продукта, который разрабатывают.
Ну и автоматизация/участие в создании воркфлоу всего этого по возможности.Понятно, что для автоматизации нужно уметь писать код, но не обязательно на уровне разработчика.
Девопс это также позиция, которая имеет влияние на архитектуру многих процессов, именно поэтому джуниор девопс - это моветон. Девопс обычно человек с опытом, и тут он может прийти и из разработчиков и из QA (автоматизейшн) и из сисадминов (что чаще всего происходит). Естественно каждый несет в свою обитель свои предыдущие знания, поэтому можно встретить девопсов которые и разрабатывают. Или которые занимаются вдобавок автотестами.
saboteur_kiev
Честно говоря, не согласен по большинству пунктов.
Тут проблемы и способы решения не на уровне джуниора, а на уровне вообще не очень дружащего с логикой человека.
Подробнее
Это как бы логично, что разработчик должен показать как работает сервис, и вообще запустить в заранее настроенной среде. В проекте должна быть инфраструктура, про которую разработчика знакомят, и еще до написания сервиса согласовывается как сервис будет запускаться, сколько ресурсов для него требуется в тестовой и продакшен среде и так далее. Ситуация когда готовый сервис попадает девопсу, а он самостоятельно думает как и где его запустить без консультации - немного нонсенс.
Эм.. это же твоя задача. Ты ее делаешь, ты привлекаешь других участников и отвечаешь за весь процесс.
Это тоже совершенно естественное поведение. Если есть ошибка, и девопс не понимает ее смысла, нужно выяснить кто понимает ее смысл и уже только после этого перекидывать задачу.
Но это не то, чтобы поведение только девопс инженера. Это задача менеджера и культуры в проекте организовать процесс так, что любой на кого упал инцидент, должен разобраться в проблеме достаточно глубоко, чтобы перенаправлять инцидент уже осознанно и если инцидент перекидывался несколько раз - такие случаи разбирать.
Внедрение продуманного решения может занять время, а продакшен не может стоять. Поэтому временные решения - отличная идея. Главное не забывать о слове "временные" в термине "временные решения".
Это вообще не проблема джунов, а вопрос вообще любого специалиста. Любая новая зависимость - инструмент, библиотека, что-нибудь еще - это еще одна зависимость, еще один кусок для поддержки, проверки и так далее. Внедрение нового чего-либо следует согласовывать с тим-лидом(тех лидом) или архитектором.
Кто ставил эту задачу с того и спрос. Я не очень понимаю как может быть задача "настроить мониторинг сервиса" без детализации. Нужные метрики или требования к мониторингу должны быть частью этой задачи.
Мониторинга нет, даже девопсы не знают что крутится на виртуальной машине?
Опять таки не вижу, чтобы это была ошибка джуна. Это прям ошибка всего проекта и подходу к инфраструктуре.
Но этот пункт, наверное первый, где я полностью согласен - девопс, как разновидность сисадмина, первый кто обязан думать о бэкапах и восстановлении, поэтому в любых действиях, которые меняют конфигурацию, это его обязанность предусмотреть восстановление и откат.
P.S. В общем основные мои претензии к статье - что ни одна из "ошибок" не относится к "джуну Девопс". Все ошибки относятся либо ко всем участникам проекта, либо к архитекторам/менеджерам/тимлидам, которые вообще никак не настраивают процессы.
dsh2dsh
Странно, а предыдущие пару десятков лет - это как-то работало. Обычная задача, когда системному администратору нужно запустить сервис. Администратор читает документацию и запускает сервис. Если обнаруживает проблемы - как минимум создаёт баг-репорты разработчику сервиса, а как максимум - исправляет и отправляет разработчику готовый патч. И вдруг внезапно появилось DevOps и древнее знание куда-то потерялось.
saboteur_kiev
Ок, а где сисадмин запускает этот сервис?
То есть ни разу не обсуждалось сколько нужно cpu/mem/disk space для сервиса?
Просто почитал документацию и пошел запускать. Видимо всегда под рукой есть свободный сервер с бесконечными ресурсами и бесплатно. И сервис никогда не тестировался, то есть ему qa/pre-prod енвайрнменты не нужны, сразу в продакшене запускаем?
Багрепорты именно сисадмин создает? Патчи сисадмин создает, реверсинженерингом?
Девопс инженер - это просто разновидность сисадминов, а не боги на все руки.
dsh2dsh
Хм... Может я не понимаю вопроса, но на контролируемых этим администратором ресурсах.
Э-э-э... с кем? Администратору поставлена задача запустить такой-то сервис. Если он считает, что у него не достаточно ресурсов для запуска этого сервиса - он об этом сообщается поставившему такую задачу. Если ресурсов достаточно - запускает сервис. Честно говоря, вопроса вообще не понял.
Да. А что в этом такого? Собственно, а как по другому. Администратору поставили задачу - он её выполняет. Если системный администратор в процессе столкнулся с какой-то проблемой и он не может её решить самостоятельно - сообщил об этом тому, кому положено в этой организации.
Э-э-э... Почему бесконечными и почему бесплатно? Системный администратор администрирует какой-то ресурс. Это могут быть сервера в серверной, в дата центре, в облаке. Если всё это загружено под завязку и новый сервис невозможно запустить в эксплуатацию - системный администратор сообщает об это ответственному за эти вопросы в этой организации. Если свободные ресурсы есть - системный администратор запускает новый сервис и настраивает всё, что необходимо для его эксплуатации с требуемым в этой организации качеством.
Это зависит от постановки задачи. Какую и как задачу поставят системному администратору - так и таким образом и будет сделано.
На да. А кто это за него сделает. Вот системный администратор запускает, ну пусть к примеру будет squid (ну или opensmtpd), да не важно что, и оно у него, к примеру, падает. Или там выжирает всю память. Или еще какое-нибудь аномальное поведение. Кто еще за системного администратор создаст баг репорт?
Да, именно он. При условии, если у него хватает на это опыта. И это, кстати, одно из отличий опытного системного администратора - от неопытного (или эникейщика). Только при чём тут реверсинжениринг. У администратора, как правило, есть исходники сервиса. Он может найти ситуацию, как воспроизвести проблему. Ну а раз уж нашёл, то возможно может и исправить её. Ну а потом сам бог послал сообщить об этом разработчикам, да приложить своё решение. Смотришь, в апстриме эту проблему и поправят. А пока будет эксплуатировать свое решение.
При чём тут боги? Обычное системное администрирование. Я таким лет 15 занимался, да и сейчас еще бывает.
saboteur_kiev
Администратор их администрирует, а не рожает.
Ок, по вашему пришел разработчик к админу и сказал вот сервис. А админ говорит а у менят нет ресурсов. Я тебе сообщил. Все?
Все почти так. Но. Если к вам пришел разработчик с готовым сервисом, то очень странно, что до этого момента он к вам не приходил и не договаривался об инфраструктуре. И сервис разрабатывался и тестировался где-то в черной дыре, ресурсы для тестовых сред на него не выделялись и вообще никто в компании не в курсе что уже год как пилят новый сервис. Вот только когда он готов, идут к сисадмину чтобы он его просто запустил.
В нормальном случае требования оговариваются заранее, так как выделить дополнительные ресурсы может занять не 1 минуту, а очень непредсказуемое время. В нормальном случае сервис и его требования вообще оговариваются заранее, чтобы не было случая, когда не особо нужный сервис требует дохрена ресурсов, которые проект не готов оплачивать.
Поэтому это все делается не во время сдачи сервиса "сисадмину", а в процессе разработки. Разработчики тоже должны знать с какой стороны ограничения по ресурсам есть в организации.
Багрепорты обычно лучше всех пишут QA инженеры и сами разработчики. Если сервис выжирает всю память, почему это происходит внезапно на продакшене? Никто не тестировал никогда?
Откуда у администратора исходники? Зачем они ему?
Вы можете как-то разобраться с апстримом, и понять что девопс отличается от сисадмина тем, что нет апстрима, код разрабатывают прямо тут с нуля, и администратор в коде не копается. Максимум конфиги.
Сколько багрепортов отписали в какие-либо ECR системы или не опен-сорс продукты? А сколько патчей отправили?