Visitors have accessed this post 3624 times.

Перевод статьи — https://medium.com/slalom-build/beginners-guid-to-devops-how-to-make-it-into-the-industry-c1652d59807

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

С учетом вышесказанного многие из нас выступают в защиту основных ценностей DevOps. Это и делает нас специалистами по DevOps. Судя по опыту, их обязанности сосредоточены вокруг следующих областей:

• Инфраструктура (облако или On-Prem)
• Мониторинг
• Автоматизация
• Сети
• Безопасность
• Непрерывная интеграция и развертывание (CI/CD)

Этим широким спектром знаний вы должны полностью овладеть, когда начинаете карьеру в DevOps, и я не уверен, что в колледже или университете есть степень, которая называлась бы «Бакалавр DevOps». Итак, как же можно начать карьеру в DevOps?

Из моего личного опыта инженеры DevOps имеют за плечами 2 бэкграунда:

1 — разработчик, который интересуется инфраструктурой и решением задач.

2 — сисадмин, который умеет и желает развиваться.

Независимо от того, какой путь вы выберете, знайте, что в DevOps вы часто будете координировать информацию от нескольких команд (бэкенд, веб-интерфейс, DB и т. д.) и постоянно находиться в центре всего происходящего. Это и хорошо, и плохо, но это зависит от того, что вы хотите извлечь из данного опыта.

Теперь, когда вы немного поняли роль инженера DevOps в компании, расскажу о некоторых личностных качествах и профессиональных навыках, которые, я считаю, являются ключом к успеху.

Полная автоматизация мышления

Ранее я упомянул, что, будучи инженером DevOps, вы не захотите, чтобы возникали какие-нибудь проблемы при развертывании. Поэтому для вас важно иметь набор инструментов, с которыми будет максимально удобно работать. Эти инструменты можно разделить на несколько категорий:

1 — инфраструктура как код (IaC), например: Terraform, CloudFormation, ARM или Google Cloud Deployment Manager.

2 — управление конфигурацией, например: Ansible, Chef, Puppet или PowerShell DSC.

3 — язык программирования для скриптов, например, Python, Bash или GO.

4 — командная строка в зависимости от вашей среды (Linux или Windows). Не стоит управлять рабочими нагрузками из пользовательского интерфейса.

5 — управление репозиторием: в этой части будет сложно продвинуться, если вы не используете Git или какую-либо форму VCS. Изучите его, включите в свои рабочие процессы, так как это сэкономит вам кучу времени.

Откровенно говоря, не имеет значения, с каким именно инструментом работать, здесь важно понять, для чего вам нужны эти инструменты. Они со временем изменятся, но навыки и концепции останутся те же.

Эти инструменты помогут вам построить конвейеры CI/CD, масштабировать и, что наиболее важно, удовлетворять потребности бизнеса в кратчайшие сроки.

Придерживайтесь своих стандартов

Все инструменты, которые мы упомянули, — отличные. Но в то же время следует упомянуть, что 2 инженера могут использовать одни и те же инструменты, но получить разные результаты. Они будут 100% рабочими и правильными, просто разными. Чтобы решить эту проблему, стоит внедрить свои стандарты кода и используемых инструментов.

Первое, что сделала наша команда, когда мы приняли Ansible, — это установка строгого стандарта YAML. Это очень важно, потому что со временем к вам присоединятся новые члены команды, и, в конечном итоге, вы можете даже открыть доступ к некоторым из инструментов разработчикам.

Документация, документация, и еще раз документация

Когда вы начнете внедрять подход IaC, инструменты управления конфигурацией и т. д., вы быстро поймете, что написание любой документации в Confluence или Wiki — это провал. Ваш декларативный код — вот ваш источник истины и рабочий документ.

Вы спросите, где мы документируем то, как все это запустить? Файл README.md в репозитории всегда сделает эту работу.

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

Коммуникация и вовлеченность

Не приступайте к решению задачи, не убедившись, что у вас есть полное понимание того, каковы цели и задачи вашей команды. Эти командные цели автоматизации, IaC и т. д. помогут вам понять, какой вклад вы вносите в работу команды, в свою карьеру и, в конечном итоге, в бизнес.

В DevOps очень важно общаться внутри вашей команды и с другими командами. Я искренне верю, что лучшие системы разрабатываются и внедряются, когда вы являетесь частью единой многофункциональной команды и каждый использует свой опыт и знания. Вы можете посмотреть и убедиться, что в Slalom Build мы относимся к этой части очень серьезно, так как она встроена непосредственно в нашу методологию разработки продуктов (PEM).

Никогда не говорите «Мы так всегда делали»

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

Стремление к обучению

В зависимости от того, в какой области DevOps вы работаете, у вас есть доступ к обучению и получению множества сертификатов, будь то облачные сервисы, такие как AWS, GCP, Azure и т. д., или даже такие инструменты, как Kubernetes, VMware, RedHat и т. д.

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

• Full Stack Radio
• Google Cloud Platform Podcast
• The InfoQ Podcast (это мой личный фаворит)
• All Things DevOps

Книга «Надежность и безотказность как в Google», является обязательной к прочтению, поскольку она помогает понять основные принципы, которые мы рассмотрели.

От редакции

Если вы хотите стать DevOps-инженером, путь будет долгим и, вероятно, непростым. Но если вам нравится постоянно учиться, разбираться в новых фичах и инструментах, копаться в настройках – нет ничего невозможного. Для тех, кто хочет освоить самые актуальные навыки DevOps-инженера на практике — мы создали практикум DevOps by Rebrain.

А еще каждую неделю мы в live режиме решаем кейсы на наших открытых онлайн-практикумах, присоединяйтесь к нашему каналу в Телеграм, вся информация там — http://rebrainme.com/channel.