Одоогийн байдлаар энэ нь зах зээл дээрх бараг хамгийн үнэтэй байр суурь юм. "DevOps" инженерүүдийн эргэн тойрон дахь шуугиан нь төсөөлж чадах бүх хязгаараас давж, DevOps ахлах инженерүүдийн хувьд бүр дорддог.
Би интеграцчлал, автоматжуулалтын хэлтсийн даргаар ажилладаг, англи хэл дээрх декодчилол - DevOps менежерийг таамаглаж байна. Англи хэл дээрх хуулбар нь бидний өдөр тутмын үйл ажиллагааг тусгах магадлал багатай боловч энэ тохиолдолд орос хувилбар нь илүү нарийвчлалтай юм. Миний үйл ажиллагааны онцлогоос шалтгаалан багийнхаа ирээдүйн гишүүдтэй ярилцлага хийх шаардлагатай байгаа нь зүйн хэрэг бөгөөд өнгөрсөн нэг жилийн хугацаанд надаар дамжин 50 орчим хүн дамжсан бөгөөд мөн ийм тооны хүмүүс манай ажилтнуудтай урьдчилсан үзлэгт хамрагдсан.
DevOps шошгоны ард янз бүрийн төрлийн инженерүүдийн маш том давхарга нуугдаж байгаа тул бид хамтран ажиллагсдаа хайж байна.
Доор бичсэн бүх зүйл бол миний хувийн бодол, та үүнтэй санал нийлэх шаардлагагүй, гэхдээ энэ нь таны сэдэвт хандах хандлагад ямар нэгэн өнгө нэмэх болно гэдгийг би хүлээн зөвшөөрч байна. Хэдийгээр олны таашаалд унах эрсдэлтэй ч гэсэн өөрийн гэсэн байр суурьтай гэдэгт итгэдэг учраас би өөрийн үзэл бодлоо нийтэлдэг.
Компаниуд DevOps-ийн инженерүүд гэж хэн бэ гэдгийг өөр өөр ойлголттой байдаг бөгөөд нөөцийг хурдан ажилд авахын тулд тэд энэ шошгыг хүн бүрт наадаг. Нөхцөл байдал нэлээд хачирхалтай байна, учир нь компаниуд эдгээр хүмүүст бодитой бус цалин хөлс төлөхөд бэлэн байдаг тул ихэнх тохиолдолд тэдний төлөө хэрэгслийн администратор авдаг.
Тэгэхээр DevOps инженерүүд гэж хэн бэ?
Түүний гадаад төрх байдлын түүхээс эхэлье - Хөгжлийн үйл ажиллагаа нь хүлээгдэж буй үр дагавар болох бүтээгдэхүүний үйлдвэрлэлийн хурдыг нэмэгдүүлэхийн тулд жижиг багуудын харилцан үйлчлэлийг оновчтой болгох өөр нэг алхам болсон юм. Энэхүү санаа нь бүтээгдэхүүний орчныг удирдах журам, арга барилын талаарх мэдлэгтэй хөгжүүлэлтийн багийг бэхжүүлэх явдал байв. Өөрөөр хэлбэл, хөгжүүлэгч өөрийн бүтээгдэхүүн нь тодорхой нөхцөлд хэрхэн ажилладагийг ойлгож, мэддэг байх ёстой, бүтээгдэхүүнээ хэрхэн байршуулах, гүйцэтгэлийг сайжруулахын тулд хүрээлэн буй орчны ямар шинж чанарыг тохируулж болохыг ойлгох ёстой. Тиймээс хэсэг хугацаанд DevOps арга барилтай хөгжүүлэгчид гарч ирэв. DevOps хөгжүүлэгчид өөрсдийн үйл ажиллагаа болон үйлдвэрлэлийн орчны гүйцэтгэлийг хялбарчлахын тулд бүтээх, савлах скрипт бичсэн. Гэсэн хэдий ч шийдлийн архитектурын нарийн төвөгтэй байдал, дэд бүтцийн бүрэлдэхүүн хэсгүүдийн харилцан нөлөөлөл нь цаг хугацааны явцад орчны гүйцэтгэлийг муутгаж эхэлсэн; давталт бүрт тодорхой бүрэлдэхүүн хэсгүүдийн талаар илүү гүнзгий ойлголттой байх шаардлагатай болж, нэмэлт өөрчлөлтийн улмаас хөгжүүлэгчийн бүтээмж буурч байв. Тодорхой үүрэг даалгаврын бүрэлдэхүүн хэсгүүд болон тааруулах системийг ойлгох зардал. Хөгжүүлэгчийн өөрийн өртөг нэмэгдэж, бүтээгдэхүүний өртөг нэмэгдэж, багийн шинэ хөгжүүлэгчдэд тавигдах шаардлага огцом өссөн, учир нь тэд хөгжлийн "од" -ын үүрэг хариуцлагыг хариуцах шаардлагатай болсон бөгөөд мэдээжийн хэрэг "од" багассан. мөн бага боломжтой. Миний туршлагаас харахад цөөхөн хөгжүүлэгчид үйлдлийн системийн цөмөөр пакет боловсруулах онцлог, пакет чиглүүлэлтийн дүрэм, хостын аюулгүй байдлын талаар сонирхож байгааг тэмдэглэх нь зүйтэй. Логик алхам бол үүнийг мэддэг администраторыг татан оролцуулж, түүнд ижил төстэй үүрэг хариуцлагыг хуваарилах явдал байсан бөгөөд энэ нь түүний туршлагын ачаар "од" бүтээн байгуулалтын өртөгтэй харьцуулахад ижил үзүүлэлтүүдэд бага зардлаар хүрэх боломжийг олгосон юм. Ийм администраторуудыг нэг багт байрлуулсан бөгөөд түүний гол үүрэг бол тухайн багт хуваарилагдсан нөөцийг тодорхой багийн дүрмийн дагуу туршилтын болон үйлдвэрлэлийн орчныг удирдах явдал байв. Үнэн хэрэгтээ DevOps олонхийн тархинд ингэж гарч ирсэн юм.
Хэсэгчилсэн эсвэл бүрмөсөн, цаг хугацаа өнгөрөхөд эдгээр системийн администраторууд хөгжлийн чиглэлээр тодорхой багийн хэрэгцээ шаардлага, хөгжүүлэгчид болон тестерүүдийн амьдралыг хэрхэн хөнгөвчлөх, шинэчлэлтийг хэрхэн нэвтрүүлэх, баасан гаригт хонох шаардлагагүй болохыг ойлгож эхэлсэн. оффис, байршуулалтын алдааг засах. Цаг хугацаа өнгөрч, одоо "одууд" нь хөгжүүлэгчид юу хүсч байгааг ойлгодог системийн администраторууд байв. Нөлөөллийг багасгахын тулд удирдлагын хэрэгслүүд гарч ирж эхлэв; бүгд OS-ийн түвшинг тусгаарлах хуучин, найдвартай аргуудыг санаж байсан бөгөөд энэ нь аюулгүй байдал, сүлжээний хэсгийг удирдах, хостын тохиргоонд тавигдах шаардлагыг багасгах боломжийг олгосон юм. бүхэлд нь, үр дүнд нь шинэ "од" -д тавигдах шаардлагыг бууруулна.
"Гайхалтай" зүйл гарч ирэв - докер. Яагаад гайхалтай гэж? Тийм ээ, зөвхөн chroot эсвэл шоронд, түүнчлэн OpenVZ-д тусгаарлалтыг бий болгох нь үйлдлийн системийн талаар өчүүхэн бага мэдлэг шаарддаг тул эсрэгээр тус хэрэгсэл нь тодорхой хост дээр тусгаарлагдсан програмын орчинг дотор болон гараараа шаардлагатай бүх зүйлийг бий болгох боломжийг олгодог. Хөгжлийн жолоог дахин давж, системийн администратор нь зөвхөн нэг хостоор удирдаж, түүний аюулгүй байдал, өндөр хүртээмжийг хангах боломжтой - логик хялбаршуулсан. Гэвч ахиц дэвшил зогсохгүй, системүүд дахин улам бүр нарийн төвөгтэй болж, улам олон бүрэлдэхүүн хэсгүүдтэй болж, нэг хост нь системийн хэрэгцээг хангахаа больж, кластер байгуулах шаардлагатай болсон тул бид дахин системийн администраторууд руу буцаж байна. Эдгээр системийг бий болгох боломжтой.
Циклийн дараагаар хөгжүүлэлт ба/эсвэл удирдлагыг хялбаршуулдаг янз бүрийн системүүд гарч ирдэг ба зохион байгуулалтын системүүд гарч ирдэг бөгөөд та стандарт процессоос хазайх хүртэл ашиглахад хялбар байдаг. Микросервис архитектур нь дээр дурдсан бүх зүйлийг хялбарчлах зорилготой гарч ирсэн - цөөн тооны харилцаа, удирдахад хялбар. Миний туршлагаас харахад би бүрэн микро үйлчилгээний архитектурыг олж чадаагүй, би микро үйлчилгээний 50-50 - 50 хувь нь хар хайрцаг, орж ирсэн, боловсруулагдсан, үлдсэн 50 нь урагдсан цул, бусад үйлчилгээнээс тусдаа ажиллах боломжгүй гэж хэлэх болно. бүрэлдэхүүн хэсгүүд. Энэ бүхэн нь хөгжүүлэгчид болон администраторуудын мэдлэгийн түвшинд дахин хязгаарлалт тавьсан.
Тодорхой нөөцийн талаархи шинжээчдийн мэдлэгийн түвшний ижил төстэй "дүүжин" өнөөг хүртэл үргэлжилж байна. Гэхдээ бид бага зэрэг ухарч, онцлон тэмдэглэх нь зүйтэй олон зүйл бий.
Барилгын инженер/хувилбарын инженер
Програм хангамж бүтээх процесс, хувилбаруудыг стандартчилах хэрэгсэл болгон гарч ирсэн маш өндөр мэргэшсэн инженерүүд. Өргөн тархсан Agile-ийг нэвтрүүлэх явцад тэд эрэлт хэрэгцээтэй байхаа больсон мэт санагдаж болох ч энэ нь тийм ч хол байна. Энэхүү мэргэшил нь үйлдвэрлэлийн хэмжээнд програм хангамжийг угсрах, хүргэх ажлыг стандартчилах хэрэгсэл болгон гарч ирэв. компанийн бүх бүтээгдэхүүнд стандарт техникийг ашиглах. DevOps гарч ирснээр хөгжүүлэгчид өөрсдийн үйл ажиллагаагаа хэсэгчлэн алдсан, учир нь хөгжүүлэгчид бүтээгдэхүүнээ хүргэхэд бэлтгэж эхэлсэн бөгөөд өөрчлөгдөж буй дэд бүтэц, чанарыг харгалзахгүйгээр аль болох хурдан хүргэх хандлагыг харгалзан тэд цаг хугацаа өнгөрөхөд тэд болж хувирав. Чанарын стандартыг дагаж мөрдөх нь хүргэлтийг удаашруулдаг тул өөрчлөлтийг зогсоодог. Тиймээс, Аажмаар, Барих/Холбогдох инженерүүдийн нэг хэсэг нь системийн администраторуудын мөрөн дээр шилжсэн.
Опууд маш өөр
Бид дахин дахин урагшилж, асар их үүрэг хариуцлага, мэргэшсэн боловсон хүчний дутагдал нь борооны дараах мөөг шиг хатуу мэргэшил рүү түлхэж байна.
- TechOps - enikey системийн администраторууд буюу HelpDesk Engineer
- LiveOps - системийн администраторууд үйлдвэрлэлийн орчныг голчлон хариуцдаг
- CloudOps - Azure, AWS, GCP гэх мэт нийтийн үүлэн дээр мэргэшсэн системийн администраторууд.
- PlatOps/InfraOps/SysOps - дэд бүтцийн системийн администраторууд.
- NetOps - сүлжээний администраторууд
- SecOps - мэдээллийн аюулгүй байдлын чиглэлээр мэргэшсэн системийн администраторууд - PCI нийцэл, CIS нийцэл, засвар хийх гэх мэт.
DevOps бол (онолын хувьд) хөгжлийн мөчлөгийн бүх үйл явц - боловсруулах, турших, бүтээгдэхүүний бүтцийг ойлгодог, аюулгүй байдлын эрсдлийг үнэлэх чадвартай, арга барил, автоматжуулалтын хэрэгслийг дор хаяж өндөр түвшинд мэддэг хүн юм. түвшин, үүнээс гадна, мөн боловсруулалтын өмнөх болон дараах боловсруулалтыг ойлгодог.бүтээгдэхүүн гаргах дэмжлэг. Үйл ажиллагаа болон хөгжлийн аль алинд нь өмгөөлөгчөөр ажиллах чадвартай хүн бөгөөд энэ нь эдгээр хоёр тулгуур баганыг хооронд нь таатай хамтран ажиллах боломжийг олгодог. Багуудын ажлыг төлөвлөх, үйлчлүүлэгчдийн хүлээлтийг удирдах үйл явцыг ойлгодог.
Энэ төрлийн ажил, үүрэг хариуцлагыг гүйцэтгэхийн тулд энэ хүн зөвхөн хөгжүүлэлт, туршилтын үйл явцыг удирдахаас гадна бүтээгдэхүүний дэд бүтцийн менежмент, нөөцийн төлөвлөлтийг удирдах чадвартай байх ёстой. Энэ ойлголт дахь DevOps нь IT, эсвэл R&D, тэр ч байтугай PMO-д байрлаж болохгүй; энэ нь эдгээр бүх салбарт нөлөө үзүүлэх ёстой - компанийн техникийн захирал, Техникийн ерөнхий захирал.
Танай компанид энэ үнэн үү? - Би эргэлзэж байна. Ихэнх тохиолдолд энэ нь IT эсвэл R&D юм.
Хөрөнгө мөнгө дутмаг, үйл ажиллагааны эдгээр гурван чиглэлийн дор хаяж аль нэгэнд нь нөлөөлөх чадваргүй байгаа нь эдгээр өөрчлөлтийг хэрэгжүүлэхэд хялбар, тухайлбал, "бохир" кодтой холбоотой хувилбаруудад техникийн хязгаарлалт тавих зэрэг асуудлын жинг өөрчлөх болно. анализаторын системүүд. Өөрөөр хэлбэл, PMO нь функцийг гаргах хатуу хугацааг тогтоосон тохиолдолд R&D нь эдгээр хугацаанд өндөр чанартай үр дүнг гаргаж чадахгүй бөгөөд үүнийг аль болох сайн гаргаж, дахин засварлах ажлыг дараа нь үлдээж, IT-тэй холбоотой DevOps нь техникийн аргаар гаргахыг хориглодог. . Нөхцөл байдлыг өөрчлөх эрх мэдэлгүй байх нь хариуцлагатай ажилчдын хувьд нөлөөлж чадахгүй зүйлдээ хэт хариуцлага хүлээхэд хүргэдэг, ялангуяа эдгээр ажилтнууд алдаагаа ойлгож, олж хардаг бол тэдгээрийг хэрхэн засах вэ - "Жаргал бол мунхаглал", Үүний үр дүнд эдгээр ажилчдыг шатаж, алдах болно.
DevOps нөөцийн зах зээл
Өөр өөр компаниудын DevOps-ийн албан тушаалын хэд хэдэн сул орон тоог харцгаая.
Хэрэв та дараах тохиолдолд бид тантай уулзахад бэлэн байна.
- Та Zabbix-ийг эзэмшдэг бөгөөд Прометей гэж юу болохыг мэддэг;
- Iptables;
- BASH докторант;
- Профессор Ансибл;
- Linux Guru;
- Дибаг хийх аргыг хэрхэн ашиглах, програмын асуудлыг хөгжүүлэгчидтэй хамт олох (php/java/python);
- Чиглүүлэлт нь таныг гистерик болгодоггүй;
- Системийн аюулгүй байдалд ихээхэн анхаарал хандуулах;
- "Юу ч ба бүх зүйл" -ийг нөөцлөх, мөн энэ "юу ч ба бүх зүйл" -ийг амжилттай сэргээх;
- Та системийг хамгийн багадаа хамгийн их байлгахын тулд хэрхэн тохируулахаа мэддэг;
- Postgres болон MySQL дээр унтахынхаа өмнө хуулбарыг тохируулах;
- CI/CD-г тохируулах, тохируулах нь танд өглөөний цай/үдийн хоол/оройн хоолтой адил шаардлагатай.
- AWS-ийн туршлагатай байх;
- Компанитай хамтран ажиллахад бэлэн байх;
Тиймээс:
- 1-ээс 6 хүртэл - системийн администратор
- 7 - бага зэрэг сүлжээний удирдлага, энэ нь системийн администраторт багтдаг, Дунд түвшний
- 8 - дунд түвшний системийн администраторт зайлшгүй шаардлагатай бага зэрэг аюулгүй байдал
- 9-11 - Дунд системийн администратор
- 12 — Өгсөн үүрэг даалгавраас хамааран дунд системийн администратор эсвэл барилгын инженер
- 13 - Виртуалчлал - Дунд системийн администратор буюу CloudOps гэж нэрлэгддэг, тодорхой байршуулах сайтын үйлчилгээний ахисан түвшний мэдлэг, хөрөнгийг үр ашигтай ашиглах, засвар үйлчилгээний ачааллыг бууруулах зорилгоор
Энэ сул орон тоог нэгтгэн дүгнэхэд залууст дунд/ахлах системийн администратор хангалттай гэж хэлж болно.
Дашрамд хэлэхэд та Linux/Windows дээрх администраторуудыг хүчтэй хувааж болохгүй. Мэдээжийн хэрэг, энэ хоёр ертөнцийн үйлчилгээ, системүүд өөр гэдгийг би ойлгож байна, гэхдээ бүхний үндэс нь нэг бөгөөд өөрийгөө хүндэлдэг админ аль алиныг нь мэддэг, мэдэхгүй байсан ч гэсэн Чадварлаг админ үүнийг мэдэхэд хэцүү биш.
Өөр нэг сул орон тоог авч үзье:
- Өндөр ачаалалтай систем барьж байсан туршлагатай;
- Линукс үйлдлийн систем, системийн ерөнхий программ хангамж, вэб стек (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK)-ийн талаар маш сайн мэдлэгтэй;
- Виртуалчлалын систем (KVM, VMWare, LXC/Docker) дээр ажиллаж байсан туршлагатай;
- Скрипт хэлний мэдлэгтэй;
- Сүлжээний протоколын сүлжээний үйл ажиллагааны зарчмуудын талаархи ойлголт;
- Гэмтлийг тэсвэрлэх системийг бий болгох зарчмуудын талаархи ойлголт;
- Бие даасан байдал, санаачлага;
Ингээд харцгаая:
- 1 - Системийн ахлах администратор
- 2 - Энэ стект оруулсан утгаас хамааран - Дунд/ахлах системийн администратор
- 3 - Ажлын туршлага нь "Кластер нь босгоогүй, харин виртуал машинуудыг үүсгэж, удирдаж байсан, нэг Docker хост байсан, контейнерт хандах боломжгүй" гэсэн утгатай байж болно - Дундаж системийн администратор
- 4 - Junior System Administrator - тийм ээ, админ биш, хэл харгалзахгүйгээр автоматжуулалтын үндсэн скриптийг хэрхэн бичихийг мэддэггүй админ - enikey.
- 5 - Дунд системийн администратор
- 6 - Системийн ахлах администратор
Дүгнэж хэлэхэд - Дунд / Ахлах системийн администратор
Өөр нэг:
- Хөгжүүлэгчийн туршлага;
- CI/CD процессыг бий болгохын тулд нэг буюу хэд хэдэн бүтээгдэхүүнийг ашиглаж байсан туршлагатай. Gitlab CI бол давуу тал болно;
- Контейнер, виртуалчлалтай ажиллах; Хэрэв та docker ашигласан бол сайн, гэхдээ та k8 ашигладаг бол гайхалтай!
- Ухаалаг багаар ажиллаж байсан туршлагатай;
- Аливаа програмчлалын хэлний мэдлэг;
Харцгаая:
- 1 - Хмм... Залуус юу гэсэн үг вэ? =) Тэд өөрсдөө үүний цаана юу нуугдаж байгааг мэдэхгүй байх магадлалтай
- 2 - Барилгын инженер
- 3 - Дунд системийн администратор
- 4 - Зөөлөн ур чадвар, бид үүнийг одоохондоо авч үзэхгүй, гэхдээ Agile бол өөр нэг зүйл бол тохиромжтой байдлаар тайлбарлагддаг.
- 5 - Хэтэрхий дэлгэрэнгүй - энэ нь скрипт хэл эсвэл эмхэтгэсэн хэл байж болно. Сургуульд Pascal болон Basic хэл дээр бичих тэдэнд тохирох болов уу? =)
Системийн администратор яагаад энэ цэгийг хамарч байгааг ойлгохын тулд би 3-р зүйлийн талаар тэмдэглэл үлдээхийг хүсч байна. Кубернетес бол зүгээр л нэг зохион байгуулалт, сүлжээний драйверууд болон виртуалчлал/тусгаарлах хостууд руу шууд командуудыг хэд хэдэн тушаалаар багтааж, тэдэнтэй хийсвэр холбоо тогтоох боломжийг олгодог хэрэгсэл юм. Жишээ нь, би фрэймворк гэж үзэхгүй байгаа "бүтээл хүрээ" Make-г авъя. Тийм ээ, би Maven-ыг шаардлагатай, шаардлагагүй газар руу түлхэх моодны талаар мэднэ - жишээлбэл, Мавенийг Мавен руу нухацтай боох уу?
Үндсэндээ Make нь зөвхөн k8s-ийн нэгэн адил эмхэтгэх, холбох, эмхэтгэх орчны командуудыг хялбаршуулж, бүрхүүлийн дээгүүр боодол юм.
Нэг удаа би OpenStack дээр ажиллаж байхдаа k8 ашигладаг залуутай ярилцлага хийсэн бөгөөд тэр үүн дээр үйлчилгээгээ хэрхэн байршуулсан тухайгаа ярьсан боловч OpenStack-ийн талаар асуухад үүнийг системээр удирдаж, өсгөсөн нь тогтоогдсон. админууд. Та үнэхээр OpenStack суулгасан хүн ард нь ямар платформ ашиглаж байгаагаас үл хамааран k8s ашиглах боломжгүй гэж бодож байна уу? =)
Энэ өргөдөл гаргагч нь үнэндээ DevOps биш, харин Системийн администратор бөгөөд илүү нарийвчлалтай хэлэхэд Кубернетес администратор юм.
Дахин нэг удаа дүгнэж үзье - Дунд / Ахлах системийн администратор тэдэнд хангалттай байх болно.
Хэр их грамм жинтэй вэ
Заасан сул орон тоонд санал болгож буй цалингийн хүрээ нь 90-200 мянга байна
Одоо би системийн администраторууд болон DevOps инженерүүдийн мөнгөн шагналын хооронд ижил төстэй зүйлийг зурахыг хүсч байна.
Зарчмын хувьд аливаа зүйлийг хялбарчлахын тулд та ажлын туршлага дээр үндэслэн дүнг тарааж болно, гэхдээ энэ нь яг тодорхой биш боловч нийтлэлд хангалттай байх болно.
Туршлага:
- 3 жил хүртэл - бага
- 6 нас хүртэл - дунд
- 6-аас дээш - Ахлах
Ажилтан хайх сайт нь дараахь зүйлийг санал болгодог.
Системийн администраторууд:
- Бага насны хүүхэд - 2 жил - 50 мянган рубль.
- Дунд - 5 жил - 70 мянган рубль.
- Ахлах - 11 жил - 100 мянган рубль.
DevOps инженерүүд:
- Бага насны хүүхэд - 2 жил - 100 мянган рубль.
- Дунд - 3 жил - 160 мянган рубль.
- Ахлах - 6 жил - 220 мянган рубль.
"DevOps"-ийн туршлагаас харахад SDLC-д ямар нэгэн байдлаар нөлөөлсөн туршлагыг ашигласан.
Дээр дурдсанаас харахад үнэндээ компаниудад DevOps хэрэггүй, мөн тэд администраторыг ажилд авснаар анх төлөвлөсөн зардлынхаа 50-иас доошгүй хувийг хэмнэж, мөн хайж буй хүнийхээ хариуцлагыг илүү тодорхой тодорхойлж чадна. хэрэгцээгээ хурдан нөхнө. Хариуцлагын тодорхой хуваарилалт нь ажилтнуудад тавигдах шаардлагыг багасгах, түүнчлэн давхцал байхгүйн улмаас багт илүү таатай уур амьсгалыг бий болгох боломжийг олгодог гэдгийг мартаж болохгүй. Сул орон тоонуудын дийлэнх нь хэрэгслүүд болон DevOps шошгуудаар дүүрэн байдаг ч тэдгээр нь DevOps инженерийн бодит шаардлагад тулгуурлаагүй, зөвхөн хэрэгслийн администраторын хүсэлтэд тулгуурладаг.
DevOps инженерүүдийг сургах үйл явц нь зөвхөн тодорхой ажил, хэрэгслүүдээр хязгаарлагддаг бөгөөд үйл явц, тэдгээрийн хамаарлын талаархи ерөнхий ойлголтыг өгдөггүй. Хүн AWS EKS-ийг Terraform ашиглан энэ кластер дахь Fluentd хажуу тэрэг болон бүртгэлийн системд зориулсан AWS ELK стектэй хамт 10 минутын дотор консол дээр зөвхөн нэг командыг ашиглан суулгаж өгөх нь мэдээж сайн хэрэг. Бүртгэлийг өөрөө боловсруулах зарчим, тэдгээрт юу хэрэгтэй вэ, хэрвээ та тэдгээрийн дээр хэмжигдэхүүнүүдийг хэрхэн цуглуулж, үйлчилгээний доройтлыг хянахаа мэдэхгүй байгаа бол зарим хэрэгслийг хэрхэн ашиглахаа мэддэг enikey хэвээр байх болно.
Гэсэн хэдий ч эрэлт хэрэгцээ нь нийлүүлэлтийг бий болгодог бөгөөд бид DevOps-ын албан тушаалын хэт халсан зах зээлийг харж байна, шаардлага нь бодит үүрэгт тохирохгүй, харин зөвхөн системийн администраторуудад илүү их орлого олох боломжийг олгодог.
Тэгэхээр тэд хэн бэ? DevOps эсвэл шунахай системийн администраторууд уу? =)
Хэрхэн үргэлжлүүлэн амьдрах вэ?
Ажил олгогчид шаардлагаа илүү нарийвчлалтай боловсруулж, шаардлагатай байгаа хүмүүсийг хайж олох ёстой бөгөөд шошго хаягдуулахгүй байх ёстой. DevOps юу хийдгийг та мэдэхгүй - энэ тохиолдолд танд хэрэггүй.
Ажилчид - Сура. Мэдлэгээ байнга сайжруулж, үйл явцын ерөнхий дүр зургийг харж, зорилгодоо хүрэх замыг хянах. Та хүссэн хүн болж чадна, чи зүгээр л хичээх хэрэгтэй.
Эх сурвалж: www.habr.com