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