Cloud-инженер на примере AWS от Слёрм

Я разработчик backend в команде Gismeteo, где мои обязанности включают поддержку и развитие существующего погодного API, настройку CI/CD Gitlab, написание ролей на Ansible и развертывание на продакшн. В нашей компании, столкнувшись с высокой нагрузкой, мы приняли решение перейти от LXC-контейнеров к Docker. Однако, учитывая объем работы, одного контейнера было недостаточно. Возник вопрос: как эффективно отслеживать и управлять всем этим? Так мы пришли к решению изучить Kubernetes. Я начал искать возможности для обучения, читал документацию, но она оказалась слишком теоретической. Понял, что без практики это просто трата времени. Попытался извлечь опыт из видео на YouTube, но опять же, практика оставалась важным компонентом. Тогда я принял решение пройти практический курс и выбрал интенсив "Слёрма". Мне было интересно поглубже изучить принципы работы Kubernetes и узнать bewt practices от опытных спикеров. Интенсивное обучение оказалось для меня наилучшим вариантом, и я даже не понадобился техподдержке. Самым увлекательным моментом курса, на мой взгляд, стало добавление отката версии Docker-образа в пайплайн для отката. Как любителя CI/CD, для меня это было особенно актуально. Также меня заинтересовала тема интеграции CI/CD с Kubernetes через Helm. Написание собственного Helm chart'а оказалось сложной, но увлекательной практической задачей. После завершения курса я убедился, что на данный момент Kubernetes является лучшим оркестратором для контейнеров. Теперь я продолжаю совершенствоваться в этом направлении, применяя полученные знания на рабочих задачах. В настоящее время пересматриваю материал курса, связанный с Helm, так как внедряю деплой через Helm для всех наших CI/CD.

Решил взглянуть на процессы в своей команде с новой точки зрения, задать вопросы о формировании требований к SLO, мониторинге и алертинге. Не ожидал чего-то революционного, но хотел понять, как это делают люди с другим опытом, взглянуть на ситуацию со стороны. Какие новые знания я уже применил на практике? После интенсива мы с командой определили обязанности лидера инцидента, внесли небольшие изменения в структуру постмортемов. Раньше некоторые аспекты не были детализированы. Во время интенсива один из членов команды поделился своим форматом постмортема. Заполняя его по нашим случаям, я обнаружил неожиданные проблемы в тех областях, которые мы раньше не рассматривали. Этот формат был успешно внедрен в нашей работе. Мы также планируем пересмотреть наши SLO и установить новые качественные метрики, чтобы отслеживать наш error budget.

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