Манай компани SRE багийг элсүүлэх шатандаа явж байна. Би энэ түүхийг бүхэлд нь хөгжлийн талаас нь харсан. Энэ явцад би бусад хөгжүүлэгчидтэй хуваалцахыг хүссэн бодол санаа, ойлголттой болсон. Энэ эргэцүүлэн бодох нийтлэлд би юу болж байгаа, энэ нь хэрхэн болж байгаа, хүн бүр үүнтэй хэрхэн үргэлжлүүлэн амьдрах талаар ярилцдаг.
Манай дотоод арга хэмжээнд хэлсэн үгн дээр үндэслэн бичсэн цуврал нийтлэлийн үргэлжлэл :
2. Дэд бүтцийг код болгон. (Та энд байна)
3. C# загваруудыг ашиглан Typescript гэрээ үүсгэх. (Явж байна...)
4. Raft зөвшилцлийн алгоритмын танилцуулга. (Явж байна...)
...
Бид санаагаа хэрэгжүүлэн SRE багийг байгуулахаар шийдсэн . Тэд өөрсдийн хөгжүүлэгчдээс програмистуудыг сонгон авч, хэдэн сарын турш сургах ажилд явуулсан.
Багийн хувьд дараах сургалтын даалгавар байсан.
- Microsoft Azure-д ихэвчлэн код хэлбэрээр байдаг манай дэд бүтцийг тайлбарлана уу (Terraform болон эргэн тойрон дахь бүх зүйл).
- Хөгжүүлэгчдэд дэд бүтэцтэй хэрхэн ажиллахыг заа.
- Хөгжүүлэгчдийг ажилд бэлтгэх.
Бид Дэд бүтцийн тухай ойлголтыг код болгон нэвтрүүлдэг
Дэлхийн ердийн загварт (сонгодог удирдлага) дэд бүтцийн талаархи мэдлэг нь хоёр газарт байрладаг.
- Эсвэл шинжээчдийн толгойд мэдлэг хэлбэрээр.
- Эсвэл энэ мэдээлэл нь зарим бичгийн машин дээр байдаг бөгөөд заримыг нь мэргэжилтнүүд мэддэг. Гэхдээ гадны хүн (манай бүхэл бүтэн баг гэнэт үхэх тохиолдолд) юу болж, хэрхэн ажилладагийг олж мэдэх нь үнэн биш юм. Машин дээр маш их мэдээлэл байж болно: дагалдах хэрэгсэл, cronjobs, айлган сүрдүүлсэн (харна уу. ) диск болон юу тохиолдож болох талаар эцэс төгсгөлгүй жагсаалт. Яг юу болоод байгааг ойлгоход хэцүү.
Энэ хоёр тохиолдолд бид өөрсдийгөө хараат байдалд оруулдаг.
- эсвэл мөнх бус, өвчинд нэрвэгдсэн, дурласан, сэтгэл санааны өөрчлөлт, зүгээр л улиг болсон хүнээс;
- эсвэл бие махбодийн хувьд ажиллаж байгаа машинаас унаж, хулгайд алдаж, гэнэтийн зүйл, таагүй байдал үүсгэдэг.
Хамгийн тохиромжтой нь бүх зүйлийг хүн унших боломжтой, хадгалах боломжтой, сайн бичсэн код болгон хөрвүүлэх ёстой гэдгийг хэлэх нь зүйтэй.
Тиймээс, дэд бүтэц нь код (Incfastructure as Code - IaC) нь одоо байгаа бүх дэд бүтцийг код хэлбэрээр тайлбарлах, түүнтэй ажиллах, бодит дэд бүтцийг хэрэгжүүлэх холбогдох хэрэгслүүд юм.
Яагаад бүгдийг код болгон хөрвүүлэх болов?Хүмүүс машин биш. Тэд бүгдийг санаж чадахгүй. Хүн, машин хоёрын хариу үйлдэл өөр. Автоматжуулсан аливаа зүйл хүний хийсэн бүх зүйлээс илүү хурдан байдаг. Хамгийн гол нь үнэний цорын ганц эх сурвалж юм.
Шинэ SRE инженерүүд хаанаас ирдэг вэ?Тиймээс бид шинэ SRE инженерүүдийг ажилд авахаар шийдсэн, гэхдээ хаанаас авах вэ? Зөв хариулттай ном () бидэнд хэлдэг: хөгжүүлэгчдээс. Эцсийн эцэст тэд кодтой ажилладаг бөгөөд та хамгийн тохиромжтой байдалд хүрдэг.
Бид тэднийг компанийхаа гаднах боловсон хүчний зах зээл дээр удаан хугацаанд хайж байсан. Гэвч бидний хүсэлтэд нийцэх хүн олдоогүй гэдгээ бид хүлээн зөвшөөрөх ёстой. Би өөрийнхөө ард түмний дунд хайх хэрэгтэй болсон.
Асуудал Дэд бүтэц код болгон
Одоо дэд бүтцийг код болгон хатуу кодлох жишээнүүдийг харцгаая. Код нь сайн бичигдсэн, өндөр чанартай, тайлбар, доголтой.
Terraforma-ийн жишээ код.
Ansible-ийн жишээ код.
Ноёд оо, ийм энгийн байсан бол! Бид бодит ертөнцөд байгаа бөгөөд энэ нь таныг гайхшруулж, гэнэтийн бэлэг, бэрхшээлийг бэлэглэхэд үргэлж бэлэн байдаг. Тэдэнгүйгээр энд бас чадахгүй.
1. Эхний асуудал бол ихэнх тохиолдолд IaC нь ямар нэгэн төрлийн dsl байдаг.
Мөн DSL нь эргээд бүтцийн тодорхойлолт юм. Нарийвчлан хэлэхэд, танд юу байх ёстой вэ: Json, Yaml, зарим томоохон компаниудын dsl-ийг гаргаж авсан өөрчлөлтүүд (HCL-ийг terraform-д ашигладаг).
Асуудал нь дараахь танил зүйлсийг агуулаагүй байж болно.
- хувьсагч;
- нөхцөл;
- хаа нэгтээ ямар ч тайлбар байхгүй, жишээлбэл, Json-д, анхдагчаар нь өгдөггүй;
- функцууд;
- Би анги, өв залгамжлал гэх мэт өндөр түвшний зүйлийн талаар ч ярихгүй байна.
2. Ийм кодтой холбоотой хоёр дахь асуудал бол ихэнхдээ энэ нь нэг төрлийн бус орчин байдаг. Та ихэвчлэн суугаад C# хэл дээр ажилладаг, i.e. нэг хэл, нэг стек, нэг экосистемтэй. Мөн энд танд маш олон төрлийн технологи байна.
Python-тэй bash нь Json-г оруулсан зарим процессыг эхлүүлэх нь үнэхээр бодит нөхцөл юм. Та үүнийг шинжилсний дараа өөр генератор өөр 30 файл үүсгэдэг. Энэ бүхний хувьд Azure Key Vault-аас оролтын хувьсагчдыг Go-д бичигдсэн drone.io-д зориулсан залгаасаар татаж авдаг бөгөөд эдгээр хувьсагч нь jsonnet загвар хөдөлгүүрээс үүсгэсэн yaml-ээр дамждаг. Ийм олон янзын орчинтой байхад нарийн тодорхойлсон кодтой байх нь маш хэцүү байдаг.
Нэг ажлын хүрээнд уламжлалт хөгжил нэг хэлээр ирдэг. Энд бид олон тооны хэлтэй ажилладаг.
3. Гурав дахь асуудал бол тааруулах явдал юм. Бидний төлөө бүх зүйлийг хийдэг редакторуудыг (Ms Visual Studio, Jetbrains Rider) дассан. Тэгээд бид тэнэг байсан ч буруу гэж хэлнэ. Энэ нь хэвийн бөгөөд байгалийн юм шиг санагддаг.
Гэхдээ ойролцоо хаа нэгтээ VSCode байдаг бөгөөд үүнд ямар нэгэн байдлаар суулгасан, дэмждэг эсвэл дэмждэггүй зарим залгаасууд байдаг. Шинэ хувилбарууд гарч ирсэн бөгөөд дэмжигдээгүй. Функцийг хэрэгжүүлэхэд улиг болсон шилжилт (энэ нь байгаа ч гэсэн) нь нарийн төвөгтэй, энгийн асуудал болж хувирдаг. Хувьсагчийн энгийн нэрийг өөрчлөх нь хэдэн арван файлын төсөлд дахин тоглуулах явдал юм. Хэрэв тэр танд хэрэгтэй зүйлээ байрлуулбал азтай байх болно. Мэдээжийн хэрэг, энд тэнд арын гэрэлтүүлэг байдаг, автоматаар бөглөх байдаг, хаа нэгтээ форматтай байдаг (хэдийгээр энэ нь Windows дээр terraform дээр надад тохирохгүй байсан).
Үүнийг бичиж байх үед 0.12 сарын турш гарсан ч 3 хувилбарыг дэмжихээр хараахан гараагүй байна.
Одоо мартах цаг болжээ...
- Дебаг хийх.
- Дахин засварлах хэрэгсэл.
- Автоматаар дуусгах.
- Эмхэтгэх явцад гарсан алдааг илрүүлэх.
Энэ нь инээдтэй, гэхдээ энэ нь хөгжүүлэлтийн хугацааг нэмэгдүүлж, зайлшгүй гарах алдааны тоог нэмэгдүүлдэг.
Хамгийн аймшигтай нь бид яаж дизайн хийх, файлуудыг хавтас болгон эмхлэх, задлах, кодыг хадгалах, унших боломжтой болгох гэх мэтийн талаар биш харин би энэ командыг хэрхэн зөв бичих талаар бодохоос өөр аргагүй болсон. .
Та анхлан суралцагчийн хувьд terraforms сурахыг хичээж байгаа бөгөөд IDE танд огт тус болохгүй. Баримт бичиг байгаа үед нь ороод хараарай. Гэхдээ хэрэв та шинэ програмчлалын хэл орж байгаа бол IDE танд ийм төрөл байдаг гэж хэлэх байсан, гэхдээ тийм зүйл байхгүй. Наад зах нь int эсвэл string түвшинд. Энэ нь ихэвчлэн ашигтай байдаг.
Туршилтуудын талаар юу хэлэх вэ?
Та: "Тестүүд яах вэ, програмистууд аа?" Ноцтой залуус үйлдвэрлэл дээр бүх зүйлийг туршиж үздэг бөгөөд энэ нь хэцүү байдаг. Вэбсайтаас terraform модулийн нэгж тестийн жишээ энд байна .
Тэд сайн бичиг баримттай. Би Microsoft-ын баримт бичиг, сургалтад хандах хандлагад нь үргэлж дуртай байдаг. Гэхдээ энэ бол төгс код биш гэдгийг ойлгохын тулд авга ах Боб байх шаардлагагүй. Баруун талд байгаа баталгаажуулалтыг анхаарна уу.
Нэгжийн тестийн асуудал бол та бид хоёр Json гаралтын зөв эсэхийг шалгах боломжтой. Би 5 параметрт оруулаад 2000 мөртэй Json хөлийн даавуу өгсөн. Би энд юу болж байгааг шинжилж, шинжилгээний хариуг баталгаажуулж чадна...
Go-д Json-г задлан шинжлэхэд хэцүү байдаг. Мөн Go-д бичих хэрэгтэй, учир нь Go-д terraform бол таны бичсэн хэлээр тест хийхэд тохиромжтой. Кодын зохион байгуулалт нь өөрөө маш сул. Үүний зэрэгцээ энэ нь тест хийх хамгийн сайн номын сан юм.
Майкрософт өөрөө модулиудаа бичиж, ийм байдлаар туршиж үздэг. Мэдээжийн хэрэг, энэ нь нээлттэй эх сурвалж юм. Миний ярьж байгаа бүх зүйл та нар ирж засч болно. Би суугаад долоо хоногийн дотор бүх зүйлийг засах боломжтой, нээлттэй эхийн VS кодын залгаасууд, terraforms, морьтондоо зориулж залгаас хийх боломжтой. Магадгүй хэд хэдэн анализатор бичиж, линтер нэмж, тест хийх номын санд хувь нэмрээ оруулах боломжтой. Би бүгдийг хийж чадна. Гэхдээ энэ бол миний хийх ёстой зүйл биш юм.
Шилдэг туршлага Дэд бүтэц нь код
Үргэлжлүүлье. Хэрэв IaC-д туршилт байхгүй, IDE болон тааруулах нь муу бол ядаж шилдэг туршлагууд байх ёстой. Би дөнгөж сая Google Analytics руу очоод Terraform шилдэг туршлагууд болон c# шилдэг туршлагууд гэсэн хоёр хайлтын асуулгыг харьцуулсан.
Бид юу харж байна вэ? Харгис статистик нь бидний талд биш юм. Материалын хэмжээ ижил байна. C# хөгжүүлэлтийн хувьд бид зүгээр л материалаар дүүрэн байдаг, бидэнд супер шилдэг туршлагууд байдаг, мэргэжилтнүүдийн бичсэн номууд, мөн эдгээр номыг шүүмжилдэг бусад мэргэжилтнүүдийн номууд дээр бичсэн номууд байдаг. Албан ёсны баримт бичиг, нийтлэл, сургалтын курс, одоо бас нээлттэй эхийн хөгжүүлэлтийн далай.
IaC хүсэлтийн хувьд: энд та өндөр ачаалал эсвэл HashiConf тайлан, албан ёсны баримт бичиг болон Github дээрх олон тооны асуудлаас бага багаар мэдээлэл цуглуулахыг оролдож байна. Эдгээр модулиудыг ерөнхийд нь хэрхэн хуваарилах вэ, тэдэнтэй юу хийх вэ? Энэ үнэхээр асуудал болоод байх шиг байна... Ноёд оо, та бүхний асуултад Github дээр 10 сэтгэгдэл өгөх нийгэмлэг байдаг. Гэхдээ яг тийм биш.
Харамсалтай нь энэ цаг үед мэргэжилтнүүд дөнгөж гарч ирж байна. Одоогоор тэдний тоо дэндүү цөөхөн байна. Тэгээд хамт олон өөрөө анхан шатны төвшинд өнжиж байна.
Энэ бүхэн хаашаа явж, юу хийх вэ
Та бүх зүйлийг орхиж, C# руу буцаж, морьтны ертөнцөд очиж болно. Гэхдээ үгүй. Хэрэв та шийдлийг олж чадахгүй бол яагаад үүнийг хийх гэж байгаа юм бэ? Доор би өөрийн субьектив дүгнэлтээ толилуулж байна. Та сэтгэгдэл дээр надтай маргаж болно, энэ нь сонирхолтой байх болно.
Би хувьдаа хэд хэдэн зүйл дээр бооцоо тавьж байна:
- Энэ чиглэлээр бүтээн байгуулалт маш хурдацтай явагдаж байна. DevOps-ийн хүсэлтийн хуваарь энд байна.
Сэдэв нь шуугиан тарьж магадгүй ч бөмбөрцөг томорч байгаа нь тодорхой итгэл найдвар төрүүлдэг.Хэрэв ямар нэгэн зүйл ийм хурдан өсөх юм бол юу хийх, юу хийх ёсгүйг хэлэх ухаалаг хүмүүс гарч ирэх нь гарцаагүй. Олны танил болсон нь хэн нэгэн vscode-д зориулсан залгаасыг jsonnet-д нэмж оруулах цаг гаргаж магадгүй бөгөөд энэ нь таныг ctrl+shift+f-ээр хайхын оронд функцийг хэрэгжүүлэхэд шилжих боломжийг олгоно. Аливаа зүйл хөгжихийн хэрээр илүү олон материал гарч ирдэг. Google-ээс SRE-ийн тухай ном гаргасан нь үүний тод жишээ юм.
- Уламжлалт хөгжилд бидний энд амжилттай хэрэгжүүлж болох боловсронгуй техник, практик байдаг. Тиймээ, туршилт, нэг төрлийн бус орчин, багаж хэрэгсэл хангалтгүй, гэхдээ хэрэгцээтэй, тустай байж болох олон тооны дадлага хуримтлуулсан байдаг.
Өчүүхэн жишээ: хос програмчлалаар хамтран ажиллах. Үүнийг ойлгоход маш их тусалдаг. Ойролцоох хөрш чинь ямар нэг зүйлийг ойлгохыг хичээж байвал хамтдаа илүү сайн ойлгох болно.
Рефакторинг хэрхэн хийгддэгийг ойлгох нь ийм нөхцөл байдалд ч гэсэн үүнийг хийхэд тусалдаг. Өөрөөр хэлбэл, та бүгдийг нэг дор өөрчлөх боломжгүй, харин нэрийг нь өөрчил, дараа нь байршлыг өөрчил, дараа нь та зарим хэсгийг тодруулж болно, өө, гэхдээ энд хангалттай тайлбар байхгүй байна.
дүгнэлт
Миний үндэслэл гутранги мэт санагдаж болох ч би ирээдүйг итгэл найдвараар харж, бүх зүйл бидний (мөн танд) бүтнэ гэж чин сэтгэлээсээ найдаж байна.
Өгүүллийн хоёрдугаар хэсгийг дараагийнх нь бэлтгэж байна. Үүнд би сургалтын үйл явцыг сайжруулах, дэд бүтэцтэй ажиллахын тулд agile хөгжлийн туршлагыг хэрхэн ашиглахыг оролдсон тухай ярих болно.
Эх сурвалж: www.habr.com