Сүүлийн үед ийм сурталчилгаа интернетээр дүүрэн байх болсон. Хэдийгээр тааламжтай цалинтай ч дотроо зэрлэг тэрс үзэл баримтлал бичигдсэнд ичихгүй байхын аргагүй. Эхлээд "DevOps" болон "инженер" хоёрыг ямар нэгэн байдлаар нэг үгээр нэгтгэж болно гэж таамаглаж байгаа бөгөөд дараа нь санамсаргүй байдлаар шаардлагын жагсаалт гарч ирдэг бөгөөд тэдгээрийн заримыг нь системийн удирдлагын сул орон тооноос тодорхой хуулж авсан болно.
Энэ нийтлэлд би амьдралынхаа энэ цэгт хэрхэн хүрсэн, DevOps гэж юу болох, үүнтэй одоо юу хийх талаар бага зэрэг ярихыг хүсч байна.
Ийм сул орон тоог бүх талаар буруушааж болох ч бодит байдал хэвээр байна: тэдгээрийн олонхи нь байгаа бөгөөд зах зээл яг ийм байдлаар ажиллаж байна. Бид devops бага хурал хийж, нээлттэй зарлаж байна: " - DevOps инженерүүдэд зориулагдаагүй." Энэ нь олон хүнд хачирхалтай, зэрлэг мэт санагдах болно: яагаад бүрэн арилжааны арга хэмжээ хийж байгаа хүмүүс зах зээлийн эсрэг явдаг вэ? Одоо бид бүгдийг тайлбарлах болно.
Соёл ба үйл явцын тухай
DevOps бол инженерийн салбар биш гэдгийг эхэлцгээе. Түүхэнд тогтсон үүргийн хуваарилалт нь бүтээгдэхүүний чанарын төлөө ажилладаггүйгээс бүх зүйл эхэлсэн. Программистууд зөвхөн программчлах боловч туршилтын талаар юу ч сонсохыг хүсэхгүй байгаа бол програм хангамж нь алдаануудаар дүүрэн байдаг. Програм хангамж хэрхэн, яагаад бичигдсэн нь админуудад хамаагүй бол дэмжлэг нь там болж хувирдаг.
Жишээлбэл, системийн администратор болон үйлчилгээний менежментийн SRE арга барилын ялгааг тайлбарлах . Дотор нь сонирхолтой судалгаанууд хийгдсэн - Шилдэг хөгжүүлэгчид ямар нэгэн байдлаар үйлдвэрлэлд шинэ өөрчлөлтүүдийг цагт нэгээс илүү хурдан нэвтрүүлж чаддаг нь ойлгомжтой. Тэд гараараа 10% -иас ихгүй туршина (үүнийг эндээс харж болно ). Тэд яаж үүнийг хийдэг вэ? Тайлангийн гарчигуудын нэг нь "Excel эсвэл үх" гэж бичжээ. Туршилтын хувьд эдгээр статистикийн талаар дэлгэрэнгүй ярихыг хүсвэл Барух Садогурскийн үндсэн илтгэлийг үзэж болно. манай бусад бага хурал дээр, Heisenbug.
"Нөхдүүдийн хооронд тохиролцоо байхгүй үед
Тэдний хувьд бүх зүйл сайн болохгүй,
Түүнээс юу ч гарахгүй, зөвхөн тарчлаана.
Эрт урьд цагт хун, хавч, цурхай..."
Таны бодлоор вэб программистуудын аль хэсэг нь тэдний хэрэглээг үйлдвэрлэлд ашиглах нөхцөлийг үнэхээр ойлгодог вэ? Тэдний хэд нь админууд дээр очоод мэдээллийн сан гацвал юу болохыг мэдэхийг оролдох вэ? Тэгээд хэн нь шалгуулагч дээр очоод шалгалтыг зөв бичихийг зааж өгөх юм бэ? Мөн хамгаалалтын ажилтнууд, бүтээгдэхүүний менежерүүд болон бусад олон хүмүүс байдаг.
DevOps-ийн ерөнхий санаа бол үүрэг, хэлтэс хоорондын хамтын ажиллагааг бий болгох явдал юм. Юуны өмнө үүнийг ухаалаг тохируулсан програм хангамж биш харин харилцааны дадлага хийх замаар олж авдаг. DevOps нь соёл, практик, арга зүй, үйл явцын тухай юм. Эдгээр асуултад хариулж чадах инженерийн мэргэжил байхгүй.
Харгис балмад тойрог
Тэр үед “devops engineering” гэдэг ухаан хаанаас ирсэн бэ? Бидэнд хувилбар байна! DevOps-ийн санаанууд маш сайн байсан бөгөөд тэд өөрсдийн амжилтын золиос болсон. Өөрийн гэсэн уур амьсгалтай зарим далд ажилчид, хүний наймаачид энэ сэдвийг бүхэлд нь тойрон эргэлдэж эхлэв.
Төсөөлөөд үз дээ: өчигдөр чи Химкид шаварма хийж байсан бол өнөөдөр та аль хэдийн том хүн, ахлах элсүүлэгч болжээ. Нэр дэвшигчдийг хайх, сонгох бүхэл бүтэн үйл явц байдаг, бүх зүйл амар биш, та ойлгох хэрэгтэй. Хэлтсийн дарга: X-д мэргэжилтэн олоорой гэж хэлье. Бид "инженер" гэдэг үгийг X-д оноож, дуусгалаа. Линукс хэрэгтэй юу? За, энэ бол мэдээж Линуксийн инженер, хэрэв та DevOps-ийг хүсч байвал DevOps-ийн инженер болно. Сул орон тоо нь зөвхөн гарчиг төдийгүй зарим текстийг дотор нь оруулах ёстой. Хамгийн хялбар арга бол таны төсөөллөөс хамааран Google-ээс түлхүүр үг оруулах явдал юм. DevOps нь "Dev" ба "Ops" гэсэн хоёр үгээс бүрддэг бөгөөд энэ нь бид хөгжүүлэгчид болон администраторуудтай холбоотой түлхүүр үгсийг бүгдийг нь нэг овоо болгон нийлүүлэх хэрэгтэй гэсэн үг юм. 42 програмчлалын хэл эзэмшсэн, Kubernetes болон Swarm программыг нэгэн зэрэг 20 жил ашигласан зэрэг сул орон тоо ингэж гарч байна. Ажлын диаграм.
Хүн бүрийг Женкинс рүү илгээхээр тохируулах тодорхой "девоп" супер баатрын утга учиргүй, өршөөлгүй дүр төрх ийнхүү хүмүүсийн тархинд суурьшиж, аз жаргал ирэх болно. Өө, бүх зүйл ийм энгийн байсан бол. "Мөн ийм байдлаар та системийн администраторуудыг хайж олох боломжтой" гэж HR "Энэ бол загварлаг үг, түлхүүр үгс нь адилхан, тэд өгөөш авах ёстой."
Эрэлт хэрэгцээ нь нийлүүлэлтийг бий болгож, энэ бүх сул орон тоо нь системийн администраторуудаар дүүрсэн бөгөөд тэд өмнөх шигээ бүх зүйлийг хийж чадна, гэхдээ өөрийгөө "девоп" гэж нэрлэснээр хэд дахин ихийг олж авах боломжтой гэдгийг ойлгосон. Та SSH-ээр серверүүдийг нэг нэгээр нь гараар тохируулсан шигээ үргэлжлүүлэн тохируулах болно, гэхдээ одоо энэ бол devops практик юм. Энэ бол сонгодог админуудын дутуу үнэлэлт, DevOps-ийн эргэн тойронд шуугиан дэгдээсэнтэй холбоотой зарим нэг нарийн төвөгтэй үзэгдэл боловч ерөнхийдөө юу болсон бэ.
Тэгэхээр бидэнд эрэлт нийлүүлэлт байна. Өөрийгөө тэжээдэг харгис тойрог. Энэ бол бидний тэмцэж байгаа зүйл юм (DevOops бага хурлыг бий болгох гэх мэт).
Мэдээжийн хэрэг, өөрсдийгөө "devops" гэж нэрлэсэн системийн администраторуудаас гадна бусад оролцогчид байдаг - жишээлбэл, мэргэжлийн SRE эсвэл Infrastructure-as-Code хөгжүүлэгчид.
DevOps-д хүмүүс юу хийдэг вэ (үнэхээр)
Тиймээс та DevOps-ийн практикт суралцаж, амьдралдаа урагшлахыг хүсч байна. Гэхдээ үүнийг яаж хийх вэ, аль зүг рүү харах вэ? Мэдээжийн хэрэг, та алдартай түлхүүр үгсэд сохроор найдах ёсгүй.
Ажил байгаа бол хэн нэгэн хийх ёстой. Эдгээр нь "devops инженер" биш гэдгийг бид аль хэдийн олж мэдсэн, тэгвэл хэн бэ? Үүнийг албан тушаалын хувьд биш, ажлын тодорхой чиглэлийн хүрээнд томъёолох нь илүү зөв юм шиг санагддаг.
Нэгдүгээрт, та DevOps-ийн зүрх сэтгэл болох үйл явц, соёлыг хөндөж болно. Соёл бол удаан бөгөөд хэцүү бизнес бөгөөд уламжлал ёсоор менежерүүдийн үүрэг хариуцлага байдаг ч програмистаас эхлээд администратор хүртэл хүн бүр ямар нэгэн байдлаар оролцдог. Хэдэн сарын өмнө Тим Листер :
“Соёл нь байгууллагын үндсэн үнэт зүйлсээр тодорхойлогддог. Ер нь хүмүүс үүнийг анзаардаггүй ч олон жил зөвлөхөөр ажилласан болохоор анзаарч дассан. Та компанид ороод хэдхэн минутын дотор юу болж байгааг мэдэрч эхэлдэг. Бид үүнийг "амт" гэж нэрлэдэг. Заримдаа энэ үнэр үнэхээр сайхан байдаг. Заримдаа энэ нь дотор муухайрах шалтгаан болдог. (...) Тодорхой үйлдлүүдийн цаад үнэ цэнэ, итгэл үнэмшлийг ойлгох хүртэл та соёлыг өөрчилж чадахгүй. Зан төлөвийг ажиглахад хялбар байдаг ч итгэл үнэмшлийг хайхад хэцүү байдаг. DevOps бол бүх зүйл улам бүр төвөгтэй болж байгаагийн гайхалтай жишээ юм."
Асуудлын техникийн хэсэг ч бий, мэдээж. Хэрэв таны шинэ код нэг сарын дараа шалгагдаж, жилийн дараа л гарвал бүгдийг хурдасгах боломжгүй бол та сайн туршлагыг дагаж мөрдөхгүй байж магадгүй юм. Сайн туршлагыг сайн хэрэгслээр дэмждэг. Жишээлбэл, Infrastructure-as-Code гэсэн санааг ашиглан та AWS CloudFormation болон Terraform-аас эхлээд Chef-Ansible-Puppet хүртэлх бүх зүйлийг ашиглаж болно. Та энэ бүхнийг мэдэж, чадвартай байх ёстой бөгөөд энэ нь аль хэдийн инженерийн салбар юм. Шалтгааныг үр дагавартай хольж хутгахгүй байх нь чухал: эхлээд SRE-ийн зарчмуудын дагуу ажиллаж, дараа нь эдгээр зарчмуудыг тодорхой техникийн шийдлүүдийн хэлбэрээр хэрэгжүүлнэ. Үүний зэрэгцээ, SRE бол Женкинсийг хэрхэн тохируулахыг заагаагүй, харин таван үндсэн зарчмыг заадаг маш өргөн хүрээтэй арга зүй юм.
- Үүрэг, хэлтэс хоорондын харилцаа холбоо сайжирсан
- Алдааг ажлын салшгүй хэсэг гэж хүлээн зөвшөөрөх
- Өөрчлөлтүүдийг аажмаар хийх
- Багаж хэрэгсэл болон бусад автоматжуулалтыг ашиглах
- Хэмжиж болох бүх зүйлийг хэмжих
Энэ бол зүгээр нэг багц мэдэгдэл биш, харин тодорхой зүйл юм . Жишээлбэл, алдааг хүлээн зөвшөөрөх замд та SLI ( гэх мэт зүйлийг ашиглан эрсдлийг ойлгож, үйлчилгээний хүртээмж, хүртээмжгүй байдлыг хэмжих хэрэгтэй болно.) ба SLO (), үхлийн дараах бичиж сур, тэдгээрийг бичих нь аймшигтай биш байх болно.
SRE сахилга батын хувьд багаж хэрэгслийг ашиглах нь амжилтын зөвхөн нэг хэсэг боловч чухал зүйл юм. Техникийн хувьд байнга хөгжиж, дэлхий дээр юу болж байгаа, үүнийг ажилдаа хэрхэн ашиглаж болохыг харах хэрэгтэй.
Хариуд нь Cloud Native шийдлүүд одоо маш их алдартай болсон. Өнөөдөр Cloud Native Computing Foundation-аас тодорхойлсончлон Cloud Native технологи нь олон нийтийн, хувийн болон эрлийз үүл зэрэг өнөөгийн динамик орчинд өргөтгөх боломжтой програмуудыг боловсруулж, ажиллуулах боломжийг байгууллагуудад олгодог. Жишээлбэл, контейнер, үйлчилгээний тор, микро үйлчилгээ, өөрчлөгддөггүй дэд бүтэц, мэдэгдлийн API-ууд орно. Эдгээр бүх техникүүд нь сул холболттой системийг уян хатан, удирдах боломжтой, ажиглах боломжтой хэвээр байлгах боломжийг олгодог. Сайн автоматжуулалт нь инженерүүдэд том өөрчлөлтүүдийг ойр ойрхон хийж, ажил хийхгүйгээр урьдчилан таамаглах боломжтой үр дүнг гаргах боломжийг олгодог. Энэ бүхнийг Docker, Kubernetes гэх мэт алдартай хэрэгслүүдийн стекээр дэмждэг.
Энэхүү нэлээд төвөгтэй бөгөөд өргөн хүрээтэй тодорхойлолт нь тухайн газар нь нэлээд төвөгтэй байдагтай холбоотой юм. Нэг талаас, энэ системд шинэ өөрчлөлт оруулах нь маш энгийн байх ёстой гэж үзэж байна. Нөгөөтэйгүүр, програм хангамжаар тодорхойлогдсон дэд бүтцэд чөлөөтэй холбогдсон үйлчилгээнүүд тасралтгүй CI/CD ашиглан тэнд хүргэгддэг нэг төрлийн чингэлэг орчинг хэрхэн бий болгох талаар олж мэдэх, энэ бүхний эргэн тойронд DevOps практикийг бий болгох - энэ бүхэн илүү ихийг шаарддаг. нэг нь нохойг идэхээс илүү.
Энэ бүхнийг яах вэ
Хүн бүр эдгээр асуудлыг өөр өөрийнхөөрөө шийддэг: жишээлбэл, харгис тойргийг эвдэхийн тулд та ердийн сул орон тоог нийтэлж болно. Та DevOps, Cloud Native гэх мэт үгсийг ямар утгатай болохыг олж мэдээд, тэдгээрийг зөв, оновчтой ашиглах боломжтой. Та DevOps дээр хөгжиж, жишээн дээрээ зөв арга барилыг харуулж чадна.
Бид хурал хийж байна , энэ нь бидний саяны ярьсан зүйлсийн талаар илүү гүнзгий судлах боломжийг олгодог. Үүнд зориулсан хэд хэдэн бүлэг тайлан байдаг:
- Үйл явц ба соёл;
- Сайтын найдвартай байдлын инженерчлэл;
- Cloud Native;
Хаашаа явахаа хэрхэн сонгох вэ? Энд нэг нарийн зүйл бий. Нэг талаас, DevOps нь харилцан үйлчлэлийн тухай бөгөөд бид таныг өөр өөр блокуудын танилцуулгад оролцохыг үнэхээр хүсч байна. Нөгөөтэйгүүр, хэрэв та тодорхой нэг даалгавар дээр анхаарлаа төвлөрүүлэхээр чуулганд ирсэн хөгжлийн менежер бол хэн ч таныг хязгаарлахгүй - энэ нь мэдээжийн хэрэг үйл явц, соёлын талаар блок байх болно. Чуулганы дараа (санал хүсэлтийн маягтыг бөглөсний дараа) бичлэг хийх болно гэдгийг бүү мартаарай, тиймээс та дараа нь чухал ач холбогдол багатай илтгэлүүдийг үзэх боломжтой.
Мэдээжийн хэрэг, чуулган дээр та нэг дор гурван замаар явж болохгүй, тиймээс бид хөтөлбөрийг цаг бүрт тохирсон сэдэвтэй байхаар зохион байгуулдаг.
Хэрэв та DevOps инженер бол юу хийхээ ойлгох л үлдлээ! Эхлээд юу хийж байгаагаа тодорхойлохыг хичээ. Ихэвчлэн тэд энэ үгийг дуудах дуртай:
- Дэд бүтэц дээр ажилладаг хөгжүүлэгчид. SRE болон Cloud Native-ийн талаархи тайлангийн бүлгүүд танд хамгийн тохиромжтой.
- Системийн администраторууд. Энд илүү төвөгтэй байна. DevOops нь системийн удирдлагын тухай биш юм. Аз болоход, системийн удирдлагын сэдвээр маш олон сайн хурал, ном, нийтлэл, видео бичлэгүүд интернетэд байдаг. Нөгөөтэйгүүр, хэрэв та соёл, үйл явцыг ойлгох тал дээр өөрийгөө хөгжүүлэх, үүлэн технологи, Cloud Native-ийн амьдралын нарийн ширийн зүйлсийн талаар суралцах сонирхолтой байгаа бол бид тантай уулзахдаа баяртай байх болно! Үүнийг бодоод үз: та захиргаа хийж байна, тэгээд та юу хийх вэ? Гэнэт тааламжгүй нөхцөл байдалд орохгүйн тулд та яг одоо сурах хэрэгтэй.
Өөр нэг сонголт бий: та өөрийгөө тийм гэж мэдэгдсээр байна ялангуяа DevOps инженер өөр юу ч биш, энэ нь юу гэсэн үг вэ. Дараа нь бид таны урмыг хугалах ёстой, DevOops бол DevOps инженерүүдэд зориулсан бага хурал биш юм!
-аас гулсуулна уу Мюнхенд
DevOops 2020 Москва 29-р сарын 30-XNUMX-ны хооронд Москвад болно, тасалбарууд бэлэн байгаа. .
Эсвэл та чадна 8-р сарын XNUMX хүртэл. Маягтыг бөглөхдөө тайлангаас хамгийн их ашиг хүртэх зорилтот үзэгчдийг сонгох ёстойг анхаарна уу (Жагсаалт дотор гэнэтийн зүйл нуугдаж байна).
Эх сурвалж: www.habr.com