DevOps // Human Help – Telegram
⌨️ Задачи (3/4)

#PersonalExperience

Днями выше рассказал вам о некоторых нюансах профессии, с которыми мне пришлось столкнуться. В рабочем процессе присутствовала неавтоматизированная лакуна — порядка 200 кликов для каждого сервера. Она включала в себя выполнение операций на хосте в аналоге live-CD режима (с операционной системой, загруженной в оперативную память) и внесение полученных результатов в таблицу. Причём по одному значению, так как вывод из консоли не был отформатирован в достаточной мере.

Но как получилось, что столь очевидная цель для автоматизации оставалась неотработанной? Дело в нестандартной конфигурации: одни и те же команды утилиты, запущенные на разном железе, показывали если и не разный вывод, то, как минимум, различное расположение ключевых значений (тех, что в итоге оказывались в таблице). Это зависело, например, от производителя. Самый простой пример такой разницы — показания температуры ядер под нагрузкой. lm-sensors, указанная в скрижалях древних, выдавала разный вывод в зависимости от того, был процессор произведён Intel или AMD. Да что там производитель — вывод отличался даже в зависимости от поколения чипа.

Методику тестирования менять было нельзя: предыдущие сотни серверов тестировались именно так, как описано в скрижалях. Если бы метод изменился, полученные цифры просто не с чем было бы сравнивать. Чтобы автоматизировать этот процесс, пришлось учитывать кучу ограничений и нюансов, потому что задача стояла — сделать всё так же, как вручную, но с автоматизацией.

Пришлось взяться за это. Ситуация осложнялась тем, что первый рабочий прототип утилиты (а это процентов 70 всей работы) я решил написать, не ставя никого в известность, используя только то время, что было выделено под тестирование серверов. Причина банальна: я не сомневался, что автоматизация возможна, и не сомневался в своей компетенции. Я думал о другом — хватит ли мне терпения довести утилиту до состояния, в котором ею сможет пользоваться кто-то, кроме меня. Потому не хотел идти к тимлиду с пустыми руками, имея лишь идею. Хотел оставить себе пути для отступления.

Не буду подробно описывать процесс разработки. Скажу лишь, что писал на Python, взяв за основу библиотеку fabric для основной части утилиты и openpyxl для парсера. Отдельную боль доставило тестирование дисков: пришлось разрабатывать для них отдельную логику, поскольку различались как их количество, так и состояние (диски могли поставляться дата-центром как в RAID, так и без него, с файловой системой нужного формата или без неё). Скрипт должен был, без ручного вмешательства, приводить диски к целевому состоянию.

В итоге мне удалось разработать прототип утилиты для тестирования, а позже довести её до ума. Спустя некоторое время я упаковал её в контейнер и сделал возможность запуска непосредственно из GitLab, соорудив для неё пайплайн.

Чем закончилась эта история и какие выводы я из неё сделал, напишу в следующей (очень надеюсь, финальной) части этого поста.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9👍55
⌨️ Задачи (4/4)

#PersonalExperience

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

Часть 1, в которой я рассказываю о типах рабочих задач и их пользе.

Часть 2, в которой я по большей части описываю различия между инфраструктурой, построенной на физических выделенных серверах, и виртуальными или облачными решениями.

Часть 3, в которой я, наконец, описываю задачу и некоторые подробности её решения.

Подведем итоги

Я решил поставленную самому себе задачу. Что получил в качестве награды?

Несколько малосонных ночей породили вполне себе рабочую утилиту для тестирования серверов. Теперь её надо поддерживать, вылавливать баги и, в случае чего, адаптировать под новые конфигурации. И делать это буду в 90% случаев я. Напоминание об ответственности за свои создания.

Аргумент, который был использован в беседе с тимлидом, посвященной необходимости повышения оплаты моего труда.

Избавление от ненавистной мне задачи, которая опасно приближала моё выгорание.

Респект и уважение от команды (скорее всего).

Что получила моя команда?

Сокращение количества действий для выполнения типовой и довольно частой задачи процентов на 90-95. Теперь она оценивается минимальным количеством стори-пойнтов. Надеюсь, что я также отсрочил чьё-то выгорание.

Вывод

Задачи, повышающие собственное work quality и work quality твоих коллег, обладают невероятным потенциалом для satisfaction. Если по-русски, то очень приятно видеть пользу от своего труда. Это помогает любить своё дело и видеть в нем смысл.

Любить свою работу полезно, потому что не любить то, чему посвящаешь треть своего времени, чревато негативными последствиями — как физического, так и ментального характера. Осознаю банальность вывода, но к чему пришёл, к тому пришёл.

Поэтому всем интересных задач, а я пошёл писать серию постов на тему K8s 101 и рисовать к ним схемы. Увидимся на следующей неделе!
Please open Telegram to view this post
VIEW IN TELEGRAM
97🔥5👍1
⌨️ Всем привет!

Завтра обещанный пост на тему K8s 101. Разберу популярный вопрос с собеседований:

«Опишите путь, который проходит Pod от момента деплоя его манифеста до статуса Running».


А прямо сейчас читайте пост Кати 👰‍♀️ о том, что писать в разделе «О себе» в резюме!
Please open Telegram to view this post
VIEW IN TELEGRAM
7🔥2
👰‍♀️ Что писать в поле “О себе”?

#рекрутинг

Представьте: вы уже вспомнили и красочно расписали весь свой опыт работы, указали полный стек, потратили на резюме немало времени, и вот появляется оно - финальный босс, поле, в которое непонятно, что писать, но и пустой оставлять не хочется. Да, речь о графе “О себе”. Давайте разбираться, чем можно ее заполнить!

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

2. Можно кратко суммировать весь свой опыт. Например “DevOps-инженер с трехлетним опытом работы в интеграторе и продуктовой компании с отличным знанием Kubernetes”.

3. Описать, что вы ищете и в каком направлении хотели бы развиваться. “Рассматриваю предложения с возможностью удаленки из-за пределов РФ и зарплатой в валюте” или “Хотел бы работать в компании, продукт которой полезен людям. Букмекерские конторы и казино не рассматриваю”.

4. Информация о ваших увлечениях вне работы совершенно не обязательна. Но если хочется сделать резюме более живым и человечным - почему бы и нет 🙂
Please open Telegram to view this post
VIEW IN TELEGRAM
🥰953👍2
⌨️ K8s. Вопрос о деплое пода

#k8s

Опишите путь, который проходит Pod от момента деплоя его манифеста до статуса Running
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥17👍852
⌨️ DataOps

#devops #вп

Кто проникся темой тут можно почитать о видах аналитиков и их обязанностях. Рядом занятный пост про💀 Квантовый апокалипсис, сегодняшней темы не касается, но мне показался интересным.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍77🔥5