Гамшгийн үед ч аяга цай уух цаг үргэлж байдаг.
DRP (гамшгаас хамгаалах төлөвлөгөө) бол хэзээ ч хэрэггүй зүйл юм. Гэвч хэрэв орооны үеэр нүүдэллэн ирж буй минжүүд гэнэт оптик шилэн кабелийг хазах юм уу эсвэл бага админ үр бүтээлтэй суурийг унагавал та энэ бүх гутамшигтай юу хийх талаар урьдчилан боловсруулсан төлөвлөгөөтэй байх болно гэдэгт итгэлтэй байх нь гарцаагүй.
Сандарсан үйлчлүүлэгчид техникийн дэмжлэг рүү залгаж, бага насны хүүхэд цианид хайж байх үед та улаан дугтуйг ухаалгаар нээж, бүх зүйлийг эмх цэгцтэй болгож эхэлнэ.
Энэ нийтлэлд би DRP-г хэрхэн бичих, түүнд юу агуулагдах талаар зөвлөмж өгөхийг хүсч байна. Мөн бид дараахь зүйлийг авч үзэх болно.
- Муу санаатан шиг сэтгэж сурцгаая.
- Апокалипсисийн үед аяга цайны ашиг тусыг харцгаая.
- Тохиромжтой DRP бүтцийг бодоорой
- Үүнийг хэрхэн туршиж үзэхийг харцгаая
Энэ нь ямар компаниудад ашигтай байж болох вэ?
Мэдээллийн технологийн хэлтэст эдгээр зүйл хэрэгтэй болж эхлэхэд шугам татах нь маш хэцүү байдаг. Дараах тохиолдолд танд DRP зайлшгүй хэрэгтэй гэж би хэлье.
- Сервер, програмыг зогсоох эсвэл зарим мэдээллийн санг алдах нь бизнесийг бүхэлд нь ихээхэн алдагдалд хүргэх болно.
- Та мэдээллийн технологийн иж бүрэн албатай. Сүлжээ татаад, вирус цэвэрлээд, принтер цэнэглээд суудаг хэдэн ядарсан ажилчид биш, өөрийн гэсэн төсөвтэй, компанийн бүрэн эрхт нэгж болох хэлтсийг хэлэх гэсэн юм.
- Онцгой байдлын үед ядаж хэсэгчлэн цомхотгол хийх бодит төсөв бий.
Мэдээллийн технологийн хэлтэс хэдэн сарын турш хуучин серверт нөөцлөхөд зориулж дор хаяж хоёр HDD гуйж байх үед та унасан үйлчилгээг нөөц хүчин чадалд бүрэн шилжүүлэх ажлыг зохион байгуулж чадахгүй байх магадлалтай. Хэдийгээр энд баримт бичиг нь хэт их байх болно.
Баримт бичиг чухал
Баримт бичгээс эхэл. Таны үйлчилгээ админуудын гурван үеийн өмнө бичигдсэн Perl скрипт дээр ажилладаг бөгөөд энэ нь хэрхэн ажилладагийг хэн ч мэдэхгүй гэж бодъё. Хуримтлагдсан техникийн өр, бичиг баримтын дутагдал нь таныг зөвхөн өвдөг төдийгүй бусад мөчрүүдэд буудах нь гарцаагүй, энэ нь цаг хугацааны асуудал юм.
Үйлчилгээний бүрэлдэхүүн хэсгүүдийн талаар сайн тайлбар хийсний дараа гэмтлийн статистикийг нэмэгдүүлээрэй. Тэд бараг бүрэн ердийн байх болно. Жишээлбэл, та дискийг үе үе дүүрсэн байдаг бөгөөд энэ нь зангилааг гараар цэвэрлэх хүртэл бүтэлгүйтэхэд хүргэдэг. Эсвэл хэн нэгэн гэрчилгээг дахин сунгахаа мартсан боловч Let's Encrypt програмыг тохируулж чадаагүй эсвэл хүсэхгүй байгаа тул үйлчлүүлэгчийн үйлчилгээ боломжгүй болно.
Хорлон сүйтгэгч шиг бодлууд
Хамгийн хэцүү зүйл бол урьд өмнө хэзээ ч тохиолдож байгаагүй, гэхдээ таны үйлчилгээг бүрэн сүйтгэж болзошгүй ослыг урьдчилан таамаглах явдал юм. Энд бид ихэвчлэн хамт ажиллагсадтайгаа муу санаатнуудын дүрд тоглодог. Их хэмжээний кофе, амттай зүйл аваад хурлын өрөөнд өөрийгөө түгжээрэй. Яг тэр уулзалт дээр та зорилтот үйлчилгээг өөрсдөө өсгөсөн эсвэл түүнтэй тогтмол ажилладаг инженерүүдийг түгжиж байгаа эсэхийг шалгаарай. Дараа нь самбар дээр эсвэл цаасан дээр та өөрийн үйлчилгээнд тохиолдож болох бүх аймшгийг зурж эхэлнэ. Тодорхой нэг цэвэрлэгч, кабелийг татах шаардлагагүй, "Дотоодын сүлжээний бүрэн бүтэн байдлыг зөрчих" хувилбарыг авч үзэхэд хангалттай.
Ихэвчлэн онцгой байдлын ихэнх тохиолдлууд дараахь төрлүүдэд хуваагдана.
- Сүлжээний доголдол
- OS үйлчилгээний алдаа
- Хэрэглээний алдаа
- төмрийн дутагдал
- Виртуалчлалын алдаа
Харагдах байдал бүрийг үзэж, таны үйлчилгээнд юу тохирохыг хараарай. Жишээлбэл, Nginx демон унаж, босохгүй байж магадгүй - энэ нь үйлдлийн системийн алдаа юм. Таны вэб програмыг ажиллахгүй байдалд оруулдаг ховор тохиолдол бол програм хангамжийн алдаа юм. Энэ үе шатыг хөгжүүлэх явцад асуудлын оношлогоог боловсруулах нь чухал юм. Виртуалчлал дээр өлгөгдсөн интерфейсийг унасан cisco болон сүлжээний эвдрэлээс хэрхэн ялгах вэ, жишээлбэл. Энэ нь буруутай хүмүүсийг хурдан олж, ослыг засах хүртэл сүүлийг нь татаж эхлэх нь чухал юм.
Ердийн асуудлуудыг бичсэний дараа бид илүү их кофе асгаж, зарим үзүүлэлтүүд нормоос хэтэрч эхлэхэд хамгийн хачирхалтай хувилбаруудыг авч үзэж эхэлдэг. Жишээлбэл:
- Идэвхтэй зангилаа дээрх цаг нь кластерын бусадтай харьцуулахад минутаар ухрах юм бол яах вэ?
- Цаг хугацаа урагшилбал 10 жилийн дараа яах вэ?
- Синхрончлолын үед кластерын зангилаа гэнэт сүлжээгээ алдвал яах вэ?
- Сүлжээгээр бие биенээ түр хугацаагаар тусгаарласны улмаас хоёр зангилаа манлайллыг хуваалцахгүй бол яах вэ?
Энэ үе шатанд урвуу арга нь маш их тусалдаг. Өвчтэй төсөөлөлтэй багийн хамгийн зөрүүд гишүүнийг авч, түүнд хамгийн богино хугацаанд эргэлтийг зохион байгуулах даалгавар өг, ингэснээр үйлчилгээг бууруулна. Хэрэв оношлоход хэцүү бол бүр сайн. Инженерүүд ямар нэг зүйлийг эвдэх санаа өгөхөд гарч ирдэг хачирхалтай, гайхалтай санаануудыг та итгэхгүй байх болно. Хэрэв та тэдэнд шалгалт өгөхийг амлавал энэ нь маш сайн хэрэг.
Чиний энэ ДРП юу вэ?!
Тиймээс та аюулын загварыг тодорхойлсон. Тэд мөн зэс хайн шилэн кабель тасалсан орон нутгийн иргэд, баасан гарагийн 16:46 цагт радио релений шугамыг хатуу буулгадаг цэргийн радар зэргийг харгалзан үзсэн. Одоо бид энэ бүгдийг юу хийхээ тодорхойлох хэрэгтэй.
Таны даалгавар бол яаралтай үед нээгдэх улаан дугтуйнуудыг бичих явдал юм. Бүх зүйл дуусахад (хэрэв биш бол!) зөвхөн хамгийн туршлагагүй дадлагажигч л ойртож, болж байгаа аймшигт үйлдлээс гар нь хүчтэй чичирнэ гэж нэн даруй хүлээх хэрэгтэй. Эмнэлгийн газруудад яаралтай тусламжийн дохио хэрхэн хэрэгжиж байгааг хараарай. Жишээлбэл, анафилаксийн шокын үед юу хийх вэ. Эмнэлгийн ажилтнууд бүх протоколыг цээжээр мэддэг боловч ойролцоох хүн үхэж эхлэхэд хүн бүр нүдэнд харагдах бүх зүйлийг арчаагүй байдлаар зуурч байдаг. Ингэхийн тулд хананд “тийм ийм юмны савыг онгойлгох”, “маш олон нэгж эмийг судсаар хийх” гэх мэт тодорхой заавар байдаг.
Яаралтай үед бодоход хэцүү байдаг! Нуруу нугасыг задлах энгийн заавар байх ёстой.
Сайн DRP нь хэд хэдэн энгийн блокуудаас бүрдэнэ.
- Ослын эхлэлийг хэнд мэдэгдэх вэ. Устгах үйл явцыг аль болох зэрэгцүүлэхийн тулд энэ нь чухал юм.
- Хэрхэн зөв оношлох вэ - бид мөшгих, systemctl статусын үйлчилгээний нэрийг харах гэх мэт.
- Та шат бүрт хэр их цаг зарцуулж чадах вэ? Хэрэв та SLA-ийн хугацаанд гараараа засах цаг байхгүй бол өчигдрийн нөөцөөс виртуал машиныг устгаж, өнхрүүлэв.
- Осол дууссан эсэхийг яаж шалгах вэ.
Үйлчилгээ бүрэн бүтэлгүйтсэн үед DRP эхэлж, үр ашиг нь буурсан ч сэргэлтээр дуусдаг гэдгийг санаарай. Зүгээр л захиалгаа алдсан нь DRP-г идэвхжүүлэх ёсгүй. Та мөн DRP-д аяга цай бичиж болно. Ноцтой. Статистикийн мэдээгээр олон осол аваар нь эвгүй байдлаас сүйрэлд хүргэдэг тул сандран сандарсан ажилтнууд ямар нэг зүйлийг засах гэж яарч, өгөгдөл бүхий цорын ганц амьд зангилааг нэгэн зэрэг устгаж эсвэл эцэст нь кластерыг дуусгаж байна. Дүрмээр бол, нэг аяга цай уух 5 минут нь тайвширч, юу болж байгааг шинжлэхэд бага зэрэг хугацаа өгнө.
DRP болон системийн паспортыг бүү андуур! Үүнийг шаардлагагүй мэдээллээр бүү ачаал. Гиперлинкээр дамжуулан баримт бичгийн шаардлагатай хэсэгт хурдан бөгөөд хялбар очиж, үйлчилгээний архитектурын шаардлагатай хэсгүүдийн талаар өргөтгөсөн хэлбэрээр унших боломжийг олго. Мөн DRP-д зөвхөн хуулж буулгах тусгай командуудыг хаана, хэрхэн холбох тухай шууд заавар байдаг.
Хэрхэн зөв тест хийх вэ
Аливаа хариуцлагатай ажилтан бүх зүйлийг дуусгах чадвартай эсэхийг шалгаарай. Хамгийн чухал мөчид инженер нь шаардлагатай системд нэвтрэх эрхгүй, шаардлагатай дансны нууц үг байхгүй, эсвэл "Үйлчилгээний удирдлагын консол руу прокси ашиглан холбогдоно уу" гэж юу болохыг мэдэхгүй байж магадгүй юм. төв оффис” гэсэн үг. Зүйл бүр аль болох энгийн байх ёстой.
Буруу байна - "Виртуалчлал руу очоод үхсэн зангилааг дахин ачаална уу"
Зөв - "Вэб интерфэйсээр virt.example.com руу холбогдож, зангилаа хэсэгт алдаа үүсгэж буй зангилааг дахин ачаална уу."
Тодорхой бус байдлаас зайлсхий. Айсан дадлагажигчийг санаарай.
DRP тест хийхээ мартуузай. Энэ бол зүгээр нэг шоуны төлөвлөгөө биш бөгөөд энэ нь танд болон таны үйлчлүүлэгчдэд эгзэгтэй нөхцөл байдлаас хурдан гарах боломжийг олгоно. Үүнийг хэд хэдэн удаа хийх нь дээр:
- Нэг мэргэжилтэн, хэд хэдэн дадлагажигчид аль болох бодит үйлчилгээг дуурайсан тестийн вандан дээр ажилладаг. Мэргэжилтэн үйлчилгээг янз бүрийн аргаар эвдэж, дадлагажигчдад DRP-ийн дагуу сэргээх боломжийг олгодог. Бүх асуудал, баримт бичгийн тодорхой бус байдал, алдаанууд бүртгэгдсэн. Дадлагажигчдыг сургасны дараа тодорхой бус газруудад DRP-ийг өргөжүүлж, хялбаршуулдаг.
- Бодит үйлчилгээнд туршилт хийж байна. Үнэн хэрэгтээ та жинхэнэ үйлчилгээний төгс хуулбарыг хэзээ ч бүтээж чадахгүй. Тиймээс, сэргээх үйл явцыг үнэлэхийн тулд жилд хэд хэдэн удаа серверүүдийн заримыг унтрааж, холболтыг таслах, аюулын жагсаалтаас бусад гамшиг үүсгэх шаардлагатай болдог. Шөнө дунд 10 минутын турш төлөвлөсөн бүтэлгүйтэл нь өгөгдөл алдагдах, ачаалал ихтэй үед хэдэн цагийн турш гэнэтийн бүтэлгүйтлээс дээр юм.
- Бодит алдааг олж засварлах. Тийм ээ, энэ нь бас туршилтын нэг хэсэг юм. Хэрэв аюул заналхийллийн жагсаалтад ороогүй осол гарсан бол түүний мөрдөн байцаалтын үр дүнд үндэслэн DRP-ийг нэмж, эцэслэх шаардлагатай.
Гол оноо
- Хэрэв дэмий хоосон зүйл тохиолдох юм бол энэ нь зүгээр л тохиолдохгүй, гэхдээ энэ нь хамгийн сүйрлийн хувилбарт үүнийг хийх болно.
- Яаралтай ачааллыг шилжүүлэх нөөц байгаа эсэхийг шалгаарай.
- Танд нөөцлөлт байгаа эсэхийг шалгаарай, тэдгээр нь автоматаар үүсгэгдэж, тогтвортой байдлыг тогтмол шалгана.
- Ердийн аюулын хувилбаруудыг авч үзье.
- Инженерүүдэд үйлчилгээ үзүүлэх стандарт бус хувилбаруудыг гаргах боломжийг олго.
- DRP нь энгийн бөгөөд бүдүүлэг заавар байх ёстой. Бүх нарийн төвөгтэй оношлогоо нь зөвхөн үйлчлүүлэгчийн үйлчилгээг сэргээсний дараа хийгддэг. Нөөц хүчин чадалтай байсан ч гэсэн.
- Үндсэн утасны дугаар, холбоо барих хаягийг DRP-д оруулна уу.
- Ажилчдын DRP-ийн талаарх ойлголтыг тогтмол шалгана.
- Үйлдвэрлэлийн талбайд төлөвлөсөн ослыг зохион байгуулах. Стенд бүгдийг орлож чадахгүй.
Эх сурвалж: www.habr.com