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