Сүлжээний инженерийн бодит байдал (гоймон ба... Давстай юу?)
Саяхан би инженерүүдтэй янз бүрийн тохиолдлын талаар ярилцаж байхдаа нэгэн сонирхолтой хэв маягийг анзаарав.
Эдгээр хэлэлцүүлгийн үеэр "үндсэн шалтгаан" гэсэн асуулт байнга гарч ирдэг. Итгэлтэй уншигчид надад байгаа гэдгийг мэдэх байх дээр Олон байгууллагад тохиолдлын шинжилгээ нь бүхэлдээ энэ үзэл баримтлалд тулгуурладаг. зэрэг шалтгаан-үр дагаврын холбоог тодорхойлохын тулд янз бүрийн арга техникийг ашигладаг Эдгээр аргууд нь "үйл явдлын шугаман байдал" гэж нэрлэгддэг зүйлийг маргаангүй догма гэж үздэг.
Хэрэв та энэ санааг эсэргүүцэж, нарийн төвөгтэй системд шугаман байдал нь итгэл үнэмшил төрүүлэхүйц хуурмаг зүйл гэдгийг онцлон хэлэхэд сонирхолтой мэтгэлцээн өрнөнө. Зөвхөн "үндсэн шалтгаан"-ын талаархи мэдлэг нь юу болж байгааг ойлгох боломжийг бидэнд олгодог гэж мэтгэлцэгчид шаргуу шаарддаг.
Би нэгэн сонирхолтой хэв маягийг анзаарсан: хөгжүүлэгчид болон DevOps энэ санааг өөр өөрөөр хүлээж авдаг. Миний туршлагаас харахад, хөгжүүлэгчид үндсэн шалтгаан нь материйг бий болгодог бөгөөд үйл явдлуудад шалтгаан үр дагаврын холбоо үргэлж бий болдог гэж маргадаг. Харин DevOps нь нарийн төвөгтэй ертөнц шугаман байдлыг үргэлж дагаж мөрддөггүй гэдэгтэй санал нийлэх магадлал өндөр байдаг.
Би үргэлж гайхдаг байсан, яагаад ийм байна вэ? Юу хүч Програмистууд яагаад "үндсэн шалтгаан нь домог" гэсэн санааг ингэж шүүмжилдэг вэ? Дархлаа нь гадны төлөөлөгчийг танихтай адил. DevOps байхад тэд яагаад ингэж хариу үйлдэл үзүүлдэг вэ арай налуу энэ санааг авч үзэх үү?
Би бүрэн итгэлтэй биш байна, гэхдээ би энэ талаар бодож байна. Энэ нь эдгээр мэргэжилтнүүдийн өдөр тутмын ажлаа гүйцэтгэдэг өөр өөр нөхцөл байдалтай холбоотой юм.
Хөгжүүлэгчид ихэвчлэн детерминист хэрэгслүүдтэй ажилладаг. Мэдээжийн хэрэг, хөрвүүлэгч, холбогч, үйлдлийн системүүд нь бүгд нарийн төвөгтэй системүүд боловч бид тэдгээр нь детерминистик үр дүнг гаргадагт дассан бөгөөд бид тэдгээрийг яг ийм байдлаар төсөөлдөг: ижил оролтын өгөгдөлтэй бол бид эдгээр системээс ихэвчлэн ижил гаралтыг хүлээж байдаг. Хэрэв гаралттай холбоотой асуудал ("алдаа") байвал хөгжүүлэгчид оролтын өгөгдөлд (хэрэглэгчээс эсвэл хөгжүүлэлтийн багцаас) дүн шинжилгээ хийх замаар шийддэг. Тэд "алдаа"-г олж, дараа нь оролтын өгөгдлийг өөрчилдөг. Энэ нь "алдаа"-г засдаг.
Програм хангамжийн инженерчлэлийн үндсэн таамаглал нь ижил оролтын өгөгдөл нь ижил үр дүнг найдвартай, тодорхой хэмжээгээр гаргадаг.
Үнэн хэрэгтээ, тодорхойлогдоогүй үр дүн нь өөрөө алдаа гэж тооцогддог: хэрэв гэнэтийн эсвэл алдаатай гаралт нь давтагдах боломжгүй бол хөгжүүлэгчид судалгааг стекийн бусад хэсгүүдэд (үйлдлийн систем, сүлжээ гэх мэт) өргөтгөх хандлагатай байдаг бөгөөд тэдгээр нь мөн ижил оролтын өгөгдөлд ижил үр дүнд хүргэдэг. хэрэв энэ нь тийм биш бол, энэ нь алдаа гэж тооцогддог. Энэ бол үйлдлийн систем эсвэл сүлжээний алдаа юм.
Ямар ч тохиолдолд детерминизм нь програмистуудын хийдэг ихэнх ажлын үндсэн, бараг л ойлгомжтой таамаглал юм.
Гэхдээ нэг өдрийн турш техник хангамж бүтээх эсвэл үүлэн API-г ашиглахад зарцуулсан аливаа DevOps-ийн мэргэжилтнүүдийн хувьд бүрэн тодорхойлогдсон ертөнцийн тухай санаа (бүх оролтын өгөгдлийг зураглах арга зам байгаа л бол!) хамгийн сайндаа л түр зуурын ойлголт юм. Бүр хойш тавиад л , туршлагатай инженерүүд энэ дэлхийн хамгийн хачирхалтай зүйлсийг харсан. Тэд үүнийг мэддэг , хүрээлэн буй орчны бусад сая сая хүчин зүйлсийг дурдахгүй байх.
Тиймээс, туршлагатай инженерүүд бүх тохиолдлууд нэг үндсэн шалтгаантай байдаг бөгөөд "Таван яагаад" гэх мэт арга техникүүд нь найдвартай (мөн дахин дахин!) үндсэн шалтгаан руу хөтөлнө гэсэн санааг эргэлзэх магадлал өндөр байдаг. Үнэн хэрэгтээ энэ нь практик дээр оньсогоны хэсгүүд хоорондоо тийм ч нягт нийцдэггүй өөрсдийн туршлагаас зөрчилддөг. Тиймээс тэд энэ санааг илүү хүлээж авдаг.
Мэдээжийн хэрэг, би хөгжүүлэгчид гэнэн, тэнэг эсвэл шугаман байдал нь хэрхэн хууран мэхэлж болохыг ойлгох чадваргүй гэж хэлэхгүй.
Гэхдээ эдгээр мэтгэлцээнд хөгжүүлэгчдийн ердийн хариу үйлдэл нь детерминизмын тухай ойлголттой холбоотой юм шиг санагдаж байна. ерөнхийдөө тэдэнд сайн үйлчилдэг тэдний өдөр тутмын ажилд. Инженерүүд дэд бүтцээсээ Шрөдингерийн муурыг барьж авахаас илүүтэйгээр тэд детерминизм бус байдалтай тулгардаг.
Энэ нь хөгжүүлэгчийн ажиглагдсан хариу үйлдлийг бүрэн тайлбарлаж чадахгүй байж болох ч бидний хариу үйлдэл нь олон хүчин зүйлийн цогц холимог гэдгийг хүчтэй сануулж байна.
Ганц тохиолдлыг олж засварлах, програм хангамж нийлүүлэх шугам дээр хамтран ажиллах, эсвэл илүү өргөн ертөнцийг ойлгохыг хичээх эсэхээс үл хамааран энэ нарийн төвөгтэй байдлыг санах нь чухал юм.
Эх сурвалж: www.habr.com
