Жий! Өглөөний 3 цаг болж байна, та гайхалтай зүүд зүүдэлж байна, гэнэт дуудлага ирлээ. Та энэ долоо хоногт жижүүртэй, ямар нэгэн зүйл болсон бололтой. Автоматжуулсан систем нь юу болж байгааг олж мэдэхийн тулд дууддаг. Энэ нь орчин үеийн компьютерийн системийг удирдах чухал тал боловч хүмүүст мэдэгдлийг хэрхэн илүү сайн болгохыг харцгаая.
Хэдэн арван жилийн турш янз бүрийн хяналтын багуудад үүрэг гүйцэтгэсэн мониторингийн философитой танилцаарай. Түүнд Роб Еващукийн жинхэнэ Библи ихээхэн нөлөөлсөн (My Notification Philosophy) дээр номонд орсон , Жон Алспаугийн ном (Сэрэмжлүүлэг тохируулах тухай тэмдэглэл).
, и - нийтлэлийг засварлахад тусалсанд баярлалаа.
CASE гэж юу вэ?
гэх мэт сайхан товчлол гаргаж ирэхээр шийдлээ буюу . Би үүнийг дууддаг CASE арга. Тэрээр автомат хяналттай ажиллахдаа анхаарах дөрвөн зүйлийг тайлбарлав.
- (контекст холбогдсон)
- (практик үнэ цэнэ)
- (шинж тэмдгүүдийг онцлон тэмдэглэх)
- (зэрэг)
Хэрэв та CASE ашигладаг бол мэдэгдэлд эрүүл хайхрамжгүй хандаж, шөнийн цагаар хүмүүсийг сэрээхгүй. Хяналт-шинжилгээ нь ашиг тустай, үр дүнтэй эсэхийг тогтмол үнэлж байх ёстой. Мэдэгдэл хүлээн авснаар хүн илүү сайн сэтгэцийн загвартай болж, өөртөө итгэлтэй болно.
Үүнийг санахад хялбар болгохын тулд танд CASE хэрэгтэй гэж төсөөлөөд үз дээ [өөрөөр хэлбэл хэрэг, шалтгаан - орчуулагчийн тэмдэглэл] дохио бүрийг зөвтгөх. :нарны шил:
Тэгээд энэ бүхэн яагаад байна вэ?
. Олон шалтгааны улмаас. Мөн CASE бүгдийг нь устгахгүй. Гэхдээ үүний тусламжтайгаар та илүү сайн мэдэгдлүүдийг авахын тулд шөнө сэрэх болно. Энэ арга нь энэ асуудалд туслах янз бүрийн зохион байгуулалтын үйл явцыг хамардаг.
RED болон USE аргуудын гоо үзэсгэлэн нь тэдний тусламжтайгаар бид хэрхэн ажиллахаа мэддэг төдийгүй өөр хоорондоо нэг хэлээр ярьдаг. CASE арга нь манай системийг хамгаалдаг боловч хамтран ажиллагсдаа завгүй байлгах мэдэгдлүүдийг хэлэлцэхэд хялбар болгоно гэж найдаж байна.
Гол нь мэдэгдэлд эрүүл хайхрамжгүй ханддаг соёлыг байгууллагадаа бий болгох хэрэгтэй. Мэдэгдэлийг тодорхой зорилгоор үүсгэж болох боловч дараа нь үнэ цэнээ алдахгүй нь үнэн биш юм. Бид яагаад энэ мэдэгдлийг тохируулсан бэ? Шалгуур үзүүлэлтүүд нь хэр удаан шинэчлэгдсэн бэ? CASE-ийн тусламжтайгаар эдгээр асуултад хариулах боломжтой.
Context-Heavy - контекст холбох
Өглөөний 3 цаг бол олон ухаалаг үг агуулсан мессежийг уншихад хамгийн тохиромжтой цаг биш юм. Үр дүнтэй хариу өгөхийн тулд танд мэдээлэл хэрэгтэй. Хамгийн тохиромжтой нь энэ нь тухайн асуудлын тухай мэдээлэл байх ёстой бөгөөд контекст нь нэн даруй тодорхой болох бөгөөд мэдэгдлийг үүнийг боломжтой байхаар тохируулсан байх ёстой. Энэ нь "ажиглалт" ба "чиг баримжаа" юм . Энэ тохиргоонд цаг зарцуулах нь ичмээр зүйл биш, учир нь хүний анхаарлыг байнга сарниулах нь илүү үнэтэй байдаг. Бие биенээ хүндэлцгээе.
Асуудал нь олон эх сурвалжтай байдаг. Ялангуяа сүнснүүд.
Би жижүүрт яаж туслах вэ? Жижүүрийн хамгийн түрүүнд хардаг зүйл бол мэдэгдэл тул түүний үндсэн дээр бүх таамаглалыг бий болгодог. Дараа нь тэр заавар, хяналтын самбарыг хардаг, гэхдээ зөвхөн ерөнхий мэдээлэл биш, тодорхой мэдэгдлийн талаархи мэдээлэл үргэлж байдаг уу? Alspaugh "Та мэдэгдлийг хэрхэн тайлбарлах эсвэл хариу өгөх талаар бодож үзээрэй" гэж зөвлөж байна (слайд 29). Сайн мэдэгдлийг зөвхөн босгогоор тохируулаад зогсохгүй жижүүрийн хүнд анхаарлаа хандуулдаг.
Тиймээс, мэдэгдлийн контекстийг хэрхэн сайжруулах талаар зарим санаанууд энд байна:
- Хэрэглэгчид энгийн заавар эсвэл хяналтын самбараас гадна хэрэгцээтэй, тусгайлан бүтээсэн зүйлийг харуул. Өмнө нь залуус бид хоёр тусгай мэдэгдэлд зориулан тохируулсан мөрдөн шалгах самбар ашигладаг байсан. Хэрэв асуудал нь мэдэгдэж байгаа бол энэ нь туслах болно, гэхдээ зөвхөн бусдыг төөрөгдүүлэх болно. Энд бид тэнцвэрийг олох хэрэгтэй.
- Мэдэгдэлийн түүхийн талаар бидэнд ярина уу: энэ нь шинэ үү? Энэ нь ихэвчлэн ажилладаг уу? Улирлын чанартай юу?
- Системийн төлөвт сүүлийн өөрчлөлтүүдийг харуул. Саяхан өөрчлөгдсөн зүйл байна уу? (Жишээ нь, байршуулах эсвэл функцийг идэвхжүүлэх/идэвхгүй болгох.)
- Харилцааг харуулж, сэтгэцийн загварт мэдээлэл өгөх: системийн хамаарал нь функциональ шинж чанартай байх нь тодорхой харагдах ёстой.
- Хэрэглэгчийг багтай хурдан холбоно уу: тэд үргэлжилж буй зөрчлийг харж чадах уу эсвэл компаниас өөр хэн мэдэгдэл хүлээн авсныг олж мэдэх боломжтой юу? Хөтөлбөр идэвхжүүлсэн үү?
Хамгийн тохиромжтой нь ослын менежментийн хөтөлбөр нь ослын мөрдөн байцаалтын мэдэгдлийн нөхцөлийг хэрхэн сайжруулах талаар зөвлөгөө өгөх болно. Үргэлж ажиллах зүйл байдаг!
Үйлдэл - практик үнэ цэнэ
Мэдэгдлийн хариуд жижүүр ямар нэг зүйл хийх ёстой юу? Хэрэв та юу ч хийх шаардлагагүй эсвэл юу хийх нь тодорхойгүй бол яагаад түүнийг сэрээсэн бэ? Та жижүүрийг залхааж, арга хэмжээ авах шаардлагагүй мэдэгдлээс зайлсхийх хэрэгтэй.
Би юу хийх хэрэгтэй вэ? Та юу хүсч байна вэ?
Өмнө нь систем нь энгийн, баг нь жижиг байсан үед бид аливаа зүйлийг хянахын тулд хяналт тавьдаг байсан. Дараа нь үйлчилгээ доголдсон тохиолдолд овоолгын ачаалал нэмэгдсэн тухай мэдэгдэл бидэнд контекстийг өгөх болно. Томоохон хэмжээнд ийм мэдэгдэл нь зөвхөн төөрөгдөл үүсгэх болно, учир нь манай системүүд үргэлж янз бүрийн ноцтой байдлын доройтлын байдалд ажилладаг. Энэ нь хурдан хүргэдэг мөн мэдээжийн хэрэг, мэдрэмж алдагдах. Тиймээс жижүүр ийм мэдэгдлийг үл тоомсорлож, бүр шүүж, шаардлагатай бол тэр бүр хариу өгдөггүй. Энэ урхинд битгий ор! Бүх мэдэгдлүүдийг дараалан тохируулаад дараа нь бурханы мартсан хавтас руу имэйлээр илгээж болохгүй.
Практик ач холбогдолтой мэдэгдэл нь дараах байдалтай байна.
- Мэдэгдэл нь зүгээр л мэдээ мэдээлэхээс илүү үйлдэл шаарддаг.
- Энэ үйлдлийг автоматжуулахад хэцүү эсвэл эрсдэлтэй. Хэрэв аливаа үйлдлийг автоматжуулах боломжтой бол автоматжуулж, хүмүүсийг бухимдуулахаа боль!
- Мэдэгдэл нь маягт дахь яаралтай зөвлөмжийг агуулдаг (SLA) эсвэл (RTO). Дараа нь жижүүр нь байгууллагын ослын менежментийн хөтөлбөрийг идэвхжүүлж болно.
Би тодруулахыг хүсч байна: Мэдэгдэл нь зөвхөн API-ийн хамгийн чухал SLO (үйлчилгээний түвшний зорилтууд)-д зориулагдсан байх ёстой гэж би хэлээгүй байна. SLO мониторинг нь байнга хуваагдаж, хуваагддаг бөгөөд бүх үйлчилгээнд ижил хандлагыг шаарддаг. Танд мөнгө төлдөг үйлчлүүлэгчдэд зориулсан хамгийн чухал SLO-г дагаж мөрдөх нь тодорхой байна. Гэхдээ мэдээллийн сан гэх мэт дэд бүтцийн SLO-г бас хянах шаардлагатай. Удалгүй та дотоод үйлчлүүлэгчидтэй харьцаж, тэднийг дэмжих хэрэгтэй болно. Гэх мэтээр хязгааргүй.
Шинж тэмдэгт суурилсан - шинж тэмдгийг онцлон тэмдэглэ
Хүссэн ч хүсээгүй ч та хуваарилагдсан системд ажиллаж байна (Каваж). Үүний үр дүнд та үйлчилгээг тусгаарлах, бүтэлгүйтлээс хамгаалахын тулд янз бүрийн тактик ашигладаг (Trainor et al.)3. Хэдийгээр хоцрогдсон хог цуглуулах эсвэл өгөгдлийн сангийн асуулга зогсонги байдалд орсон нь асуудал байгааг илтгэж байгаа ч хэрэглэгчид ойрын ирээдүйд асуудал гарахгүй бол тэдгээрийг засах гэж яарах шаардлагагүй болно.
Эдгээр нь чухал дохио бөгөөд практик ач холбогдолтой байж болох ч хэрэв хэрэглэгчдэд саад болохгүй бол үйлчлэгчийн анхаарлыг сарниулах нь тийм ч яаралтай биш юм. Шалтгаан дээр суурилсан мэдэгдэл нь системийн доголдлын талаарх бидний сэтгэцийн загваруудын агшин зуурын зураг юм. Амжилтанд хүргэж болзошгүй бүх шалтгааныг жагсаахаас илүү чухал шинж тэмдгүүдийг хянах нь дээр.
Мэдэгдэлийг утга учиртай болгохын тулд анхаарлаа хандуулаарай , хэрэглэгчдэд чухал ач холбогдолтой. Еващук үүнийг "хэрэглэгчийн хяналт" гэж нэрлэдэг. Энэ философийг байгууллагын хэмжээнд хэрэгжүүлэх ёстой гэдгийг санаарай. Хэрэв аль нэг үйлчилгээ нь дэд бүтцийн хаа нэгтээ яаралтай асуудалтай байвал зохих баг нь шийдвэрлэх болно. Системийг ийм бүтэлгүйтлээс хамгаалах нь тусдаа асуудал юм (Сургагч нар, чухал хамаарлыг багасгах стратегийн хэсэг).
Шинж тэмдгүүд нь өөрчлөгддөггүй
Ричард Күүк нарийн төвөгтэй системүүд нь дутагдал, дутагдал, асуудлуудаар дүүрэн байдаг гэдгийг бидэнд сануулж байна. Боломжит бүх шалтгааныг жагсаахыг хичээх нь Сисифийн даалгавар юм. Та асуудлыг тайлбарлах гэж оролддог боловч тэдгээр нь үргэлж өөрчлөгддөг. Синди Шридхаран "системүүд секунд тутамд төгс байдалд байх албагүй" гэж үздэг бөгөөд илүү хүний хандлагыг ашиглах нь дээр ( (“Түгээмэл системийг хянах”), 7).
Үйл явдлын дараа мэдэгдэл өгөхөөс зайлсхий
Ихэвчлэн шалтгаануудын мэдэгдлийг тохиолдлыг засахаар тохируулдаг. Болсон явдлын талаархи эдгээр хязгаарлагдмал мэдэгдэл нь аюулгүй байдлын хуурамч мэдрэмжийг бий болгодог, учир нь систем нь эвдэх шинэ арга замыг байнга гаргаж ирдэг.
Шалтгааны мэдэгдэлд бүү хуурт. Илүү сайн бодоорой:
- Шинж тэмдэгт суурилсан мэдэгдэл яагаад асуудлыг анзаараагүй вэ?
- Энэ нь хэрэглэгчдэд контекстийг сайжруулахад тустай байх болов уу?
- Юу болсон талаар мэдэгдэл цуглуулахын оронд оношийг хурдан гаргахын тулд хяналтын хэрэгслийг хэрхэн сайжруулах вэ?
Оношлогооны хяналтын хэрэгслүүд нь шинж тэмдгүүдээс шийдэл рүү шилжих арга гэж үзвэл л тус болно. Энэ санал хүсэлт байхгүй бол та зүгээр л хожимдсон мэдэгдэл, өнгөрсөн бүтэлгүйтлийн тухай графикаар бөмбөгдөх болно - ирээдүйн алдааны талаар нэг ч үг биш. Байгууллага хамгаалалтаас довтолгоонд шилжих сайхан боломж юм. Мөн хөгжүүлэгчид болон бүтээгдэхүүний менежерүүд ижил хүлээлт, тодорхой зорилготой байх болно. Кейс - CASE (:wink:) - мэдэгдэл бүрт тодорхой байна.
Шалтгаан дээр үндэслэсэн мэдэгдлүүдийг дунд зэрэгтэй зөвшөөрч болно
Заримдаа манай систем шалтгаан дээр суурилсан мэдэгдлийн хувьд бидэнд сонголт багатай үлдээдэг. Заримдаа жижүүрүүд нь шинж тэмдэг нь бүтэлгүйтэлд хүргэдэг гэдгийг маш сайн ойлгодог тул практик ач холбогдолтой байдаг. Магадгүй та юу болж байгааг сайн мэдэхгүй байгаа бөгөөд аюулгүй байдлыг хангах үүднээс мэдэгдлүүдийг тохируулж байгаа байх. Гүйцэтгэлийн асуудлыг шийдвэрлэхийн тулд системийг өөрчлөх хүртэл энэ үйлдэл түр зуурынх байх гэж найдаж байна.
Эдгээр нөхцөл байдлыг шийдвэрлэхдээ CASE-ийн бусад бүрэлдэхүүн хэсгүүдийг санаарай. Энэ нь түр зуурынх учраас толгойгоо бодохоо болино гэсэн үг биш.
Үнэлгээтэй - үнэлгээ
Системд гарсан аливаа өөрчлөлт (шинэ код, шинэ дэд бүтэц, шинэ зүйл) нь бүтэлгүйтлийн хүрээг өргөжүүлдэг (Күүк, 3). Энэ мэдэгдэл хүлээгдэж буй байдлаар ажиллаж байна уу? Системийн тодорхой бөгөөд одоогийн сэтгэцийн загварууд болон зарим дэмжлэгийн мэдэгдэлд хариу үйлдэл үзүүлэх туршлага - Эдгээр нь гол шинж чанарууд юм . Системийн согогууд байнга хувьсан өөрчлөгдөж байдаг тул бид тэдгээрийг дагаж мөрдөх ёстой.
Мэдэгдэл тус бүрийг хүлээгдэж буйгаар нь ажиллуулахын тулд та түүний чанарыг байнга үнэлж байх хэрэгтэй. Эрхэм удирдагчид! Хэрэв та энэ үйл явцыг бий болгоход нь тусалбал танай багуудад илүү хялбар байх болно! Энд зарим үнэлгээний санаанууд байна:
- Ашиглах , эсвэл бусад мэдэгдлийн туршилтын аргууд. Баг нь ослын менежментийн системд найдах шаардлагагүйгээр өөрсдөө хийж чадна!
- Осолтой холбоотой бүх мэдэгдлийн цуглуулгыг ослын менежментийн хөтөлбөртөө оруулаарай. Ашигтай, хортой, тохиромжгүй, ойлгомжгүй гэх мэтийг тэмдэглэ. Тэдгээрийг санал хүсэлт болгон ашиглаарай.
- Зөв мэдэгдлүүд нь ховор тохиолддог бөгөөд сайтар шалгадаг. Бүх холбоосууд ажиллаж, зөв контекстийг зааж байгаа эсэхийг шалгаарай.
- Хэрэв мэдэгдэл хэзээ ч асахгүй эсвэл хэт олон удаа асдаг бол ямар нэг зүйл буруу байна. Үүнийг засах эсвэл арилгах. Хэт идэвхгүй байдал, үйл ажиллагаанаас болгоомжил!
- Дуусах огноо бүхий мэдэгдлийн цагийг тохируулна уу. Хэрэв хугацаа нь дууссан бол CASE аргыг ашиглан мэдэгдлийг үнэлж, цагийн тэмдгийг шинэчилнэ үү. Хоолны нэгэн адил хугацаа дуусах хугацааг тогтмол шалгаж үзээрэй.
- Мэдэгдэлийг сайжруулах үйл явцыг хялбарчлах. Хяналтыг код болгон ашиглаж, мэдэгдлүүдийг Git репозитор дээр хадгал. Татаж авах хүсэлт нь багийг татан оролцуулж, танд өнгөрсөн мэдэгдлийн түүхийг өгөхөд тусалдаг. Мөн та мэдэгдлийг өөрчлөх эсвэл хариуцагчаас зөвшөөрөл авахаас айхаа болино.
- Энгийн байсан ч мэдэгдлийн санал хүсэлтийг тохируулаарай , ингэснээр жижүүрүүд мэдэгдлийг ашиггүй эсвэл хөндлөнгийн гэж тэмдэглэнэ. Мэдэгдэлд холбоос эсвэл үйлдэл хийх уриалгыг оруулж, санал хүсэлтээ тогтмол хянаж байгаарай.
- Багийн бүрэлдэхүүнд дүрэм тогтоо - ажил багатай үед жижүүрийг хялбарчлахын тулд ажилла. Таны дараах бүх зүйл өмнөхөөсөө арай дээрдэх болтугай.
дүгнэлт
CASE арга нь хөгжүүлэгчид болон байгууллагуудад автоматжуулсан мэдэгдлийг тохируулах, илгээх талаар ярилцахад тусалдаг гэдэгт би итгэдэг. Нэг хөгжүүлэгч CASE аргыг ашиглан мэдэгдлийг үнэлж эхлэх ба дараа нь бүх байгууллага бусад хөгжүүлэгчид, удирдлага, ослын менежментийн хөтөлбөрүүдтэй нэгдэж, мэдэгдлийг хэвийн байлгах болно. Энэ нь тусгай хэрэгсэл, нарийн төвөгтэй процесс шаарддаггүй.
Үйлчлүүлэгчийн дээд зэрэглэлийн үйлчилгээг алдалгүйгээр ажил үүргээ гүйцэтгэж байхдаа хүний хүчин зүйлийг бүхэлд нь бодох хэрэгтэй. Эдгээр бүх хэрэгсэл, дадлыг сайжруулах боломжтой бөгөөд сайжруулах ёстой. Үүнд CASE арга тусална гэж найдаж байна.
Сайжруулсан мэдэгдлүүдийг сайхан өнгөрүүлээрэй!
Эх сурвалж: www.habr.com