Ръководство за начинаещи в DevOps: Как да го превърнем в индустрията

Ако започвате кариерата си или търсите преход в DevOps едно от първите неща, които ще научите е, че DevOps е методология повече от длъжност. DevOps в основата си има за цел да преодолее всяко разделение между ИТ операциите и развитието, за да насърчи сътрудничеството и участието между двете страни, за да намали всички изненади до момента, в който приложението трябва да бъде внедрено в Производство, със силен акцент върху автоматизацията и стандартизацията.

С казаното, има много от нас, които проповядват основните ценности на DevOps и имат набор от отговорности, които са посветени на методологията на DevOps, като по този начин ни правят DevOps инженери. От моя опит някои от тези отговорности са фокусирани около тези области:

  • Инфраструктура (облак или предварително)
  • мониторинг
  • Автоматизация
  • Работа в мрежа
  • Сигурност
  • Пускане и внедряване (CI / CD)

Очевидно това е широк спектър от знания, за да бъдете напълно владеещи, тъй като започвате кариерата си в DevOps, и не вярвам, че има колеж или университетска степен, наречена „бакалавър на DevOps“. И така, как останалите започнахме своята кариера на DevOps?

От моя опит инженерите на DevOps произхождат от 2 фона:

1- Разработчик с интерес към инфраструктурата и операциите.

2- системен администратор със силни умения за развитие.

Независимо какъв път поемете или дори ако сте искали да започнете кариерата си веднага в DevOps, поради естеството на DevOps често се оказвате, че координирате информация от множество екипи (бекенд, фронт, DB и т.н.) и сте в център на всичко. Това е едновременно благословия и проклятие, но това зависи от това, което искате да извадите от опита.

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

Автоматизирайте всичко манталитет:

https://xkcd.com/974/

Споменах накратко преди това като DevOps инженер, че не бихте искали да бъдете блокер за внедряване. Така че за вас като DevOps инженер е важно да имате набор от инструменти, с които сте супер удобни. И наистина тези инструменти могат да бъдат разделени на няколко категории:

1- Инфраструктура Като код, примери са Terraform, CloudFormation, ARM или Google Cloud Deployment Manager.

2- Управление на конфигурацията, примерите са Ansible, Chef, Puppet или PowerShell DSC

3- Език на скриптове, примерите са Python, Bash или GO

4- Команден ред, в зависимост от вашата среда (Linux или Windows), но влезте там много удобно. Забравете за управление на работните натоварвания от потребителски интерфейс.

5- Управление на хранилищата, няма да стигнете далеч в тази индустрия, ако не приемете Git или някаква форма на VCS. Научете го, приемете го във вашия работен процес, тъй като това ще ви спести един ден.

За да бъдете кристално чисти точният инструмент, на който се приземявате, е без значение, тук е важно да разберете какво и защо имате нужда от тези инструменти. Тези точни инструменти ще променят извънредния труд, но уменията и концепциите са прехвърлими.

Тези инструменти ще ви помогнат да направите ad hoc промени, да изградите CI / CD тръбопроводи, мащаб и най-важното да осигурите бизнес нуждите в най-кратки срокове.

Придържайте се към вашите стандарти:

Всички споменати от нас инструменти са страхотни, но дума за предпазливост е, че 2 инженера могат да използват същите точни инструменти, но в крайна сметка при различно изпълнение. И двете могат да бъдат 100% валидни и правилни, просто различни. За да решите това, създайте или приемете стандарт за кодиране и инструментариум.

Едно от първите неща, които екипът ми направи, когато приехме Ansible, беше да установи строг стандарт YAML. Това е изключително важно, защото с течение на времето ще имате нови членове на екипа и в крайна сметка може дори да отворите част от инструментите си и за разработчици.

Документ, документ, документ:

Когато започнете да приемате IaC, Инструменти за управление на конфигурацията и т.н., бързо ще разберете, че писането на всяка документация в Confluence или Wiki е загубена битка. Вашият „Декларативен код“ се превръща в източник на истината и вашият работен документ.

Но вие ще попитате, къде да документираме как да стартирате всичко това? Бих казал, че файлът README.md в репо винаги ще свърши работа.

Винаги се уверете, че вашият проект е отчел документация и това включва коментиране на вашия код. По-лесно ми е да го правя, докато се развивам, а не в края.

Комуникация и ангажиране:

Не настройвайте щорите си и работете върху задача, без да сте сигурни, че имате пълно разбиране за това, каква е визията и целите на вашия екип. Тези екипни цели за автоматизация, инфраструктура като код и т.н. ще ви помогнат да разберете как положително допринасяте за екипа, за собствената си кариера и в крайна сметка за бизнеса.

За DevOps особено трябва да комуникирате в рамките на вашия екип и външно с други екипи. Наистина вярвам, че най-добрите системи са проектирани и внедрени, когато сте част от крос функционален екип и всеки предлага своите експертизи и опит. В Slalom Build можете да видите, че ние приемаме тази част много сериозно, тъй като е вградена директно в нашата методология за продуктови инженеринги (PEM).

Никога не казвайте „Така сме го правили винаги“:

Чувал съм този път твърде често в кариерата си, състоянието на DevOps винаги се измества и се движи, ако сте направили нещо по един начин, винаги има място за подобрение. Дръжте отворен ум за нови идеи и нови инструменти.

Голям усет за учене:

В зависимост от това върху коя област в DevOps сте фокусирани, има много сертификати, които можете да направите, било от облачни доставчици като AWS, GCP, Azure и т.н. или дори от инструменти като Kubernetes, VMware, RedHat и т.н.

Сертификатите са страхотни, тъй като помагат да ви дадат основни знания, но смятам, че не ви дава реално житейско преживяване, което може да се различава по-силно от тест. За да преодолея разликата между тези две, намирам четенето на статии и слушането на подкасти помага да се изгради това преживяване малко, но нищо не бие реални преживявания в реалния живот. Някои подкасти, които слушам, за да поддържам връзка с новите разработки и да помогна малко да заобикаля опита си:

  • Пълен стек радио
  • Google Cloud Platform Podcast
  • Подкастът InfoQ (това е моят личен фаворит)
  • Всички неща DevOps

Нещо повече, книгата за надеждност на сайта за надеждност на Google е задължително прочетена в нашата индустрия, тъй като ще ви помогне да разберете няколко основни понятия, които разгледахме тук.