Тіпті апат кезінде де бір шыны шай ішуге уақыт болады
DRP (апаттарды қалпына келтіру жоспары) - бұл ешқашан қажет болмайтын нәрсе. Бірақ егер кенеттен жұптасу маусымында қоныс аударатын құндыздар магистральдық оптикалық талшықты кемірсе немесе кіші әкімші өнімді негізді түсіріп алса, сізде осы масқарамен не істеу керектігі туралы алдын-ала жасалған жоспарыңыз болатынына сенімді болғыңыз келеді.
Дүрбелеңдегі тұтынушылар техникалық қолдау телефондарын өшіре бастағанда, кіші цианид іздейді, сіз қызыл конвертті ақылмен ашып, бәрін ретке келтіре бастайсыз.
Бұл постта мен DRP қалай жазу керек және ол нені қамтуы керектігі туралы ұсыныстармен бөліскім келеді. Біз сондай-ақ келесі нәрселерді қарастырамыз:
- Зұлым адам сияқты ойлауды үйренейік.
- Ақырзаман кезінде бір кесе шайдың пайдасын көрейік.
- Ыңғайлы DRP құрылымын ойластырайық
- Оны қалай тексеруге болатынын көрейік
Бұл қай компаниялар үшін пайдалы болуы мүмкін?
IT бөліміне мұндай нәрселер қажет бола бастағанда сызықты сызу өте қиын. Мен сізге міндетті түрде DRP қажет деп айтар едім, егер:
- Серверді, қолданбаны тоқтату немесе кейбір дерекқорды жоғалту жалпы бизнес үшін айтарлықтай шығындарға әкеледі.
- Сізде толыққанды IT бөлімі бар. Желі салып, вирустарды тазалап, принтерлерді толтырып жатқан бірнеше шаршаған қызметкерлер емес, өз бюджеті бар компанияның толыққанды бөлімшесі түріндегі бөлім деген мағынада.
- Сізде төтенше жағдайда кем дегенде ішінара жұмыстан босату үшін нақты бюджет бар.
АТ бөлімі сақтық көшірме жасау үшін ескі серверге кем дегенде бірнеше HDD дискілерін айлар бойы сұраған кезде, сіз сәтсіз қызметтің сыйымдылықты резервтеу үшін толыққанды көшуін ұйымдастыра алмайсыз. Бұл жерде құжаттама артық болмайды.
Құжаттама маңызды
Құжаттамадан бастаңыз. Сіздің қызметіңіз үш ұрпақ бұрын әкімшілер жазған Perl сценарийінде жұмыс істейді делік, бірақ оның қалай жұмыс істейтінін ешкім білмейді. Жинақталған техникалық қарыз және құжаттаманың болмауы сізді тек тізеңізге ғана емес, сонымен қатар басқа аяқ-қолыңызға да түсіреді, бұл уақыт мәселесі.
Қызмет компоненттерінің жақсы сипаттамасын алғаннан кейін, жазатайым оқиғалар статистикасын іздеңіз. Олар, әрине, толығымен типтік болады. Мысалы, дискіңіз мезгіл-мезгіл толып қалады, бұл түйін қолмен тазартылғанша істен шығады. Немесе біреудің сертификатты жаңартуды ұмытып кетуіне және Let's Encrypt қолданбасының конфигурациялау мүмкін болмауына немесе конфигурациялауды қаламауына байланысты клиент қызметі қолжетімсіз болады.
Диверсант сияқты ойлар
Ең қиын бөлігі - бұрын ешқашан болмаған, бірақ қызметіңізді толығымен бұзуы мүмкін апаттарды болжау. Мұнда әріптестерім екеуміз әдетте зұлым адамдарды ойнаймыз. Көп кофе мен дәмді нәрсе алыңыз да, өзіңізді жиналыс бөлмесіне кіргізіңіз. Дәл сол келіссөздерде мақсатты қызметті өздері әзірлеген немесе онымен үнемі жұмыс істейтін инженерлерді құлыптағаныңызға көз жеткізіңіз. Содан кейін, тақтада немесе қағазда сіз өзіңіздің қызметіңізде болуы мүмкін барлық сұмдықтарды сыза бастайсыз. Белгілі бір тазалаушыға және кабельдерді тартуға дейін егжей-тегжейлі айтудың қажеті жоқ, «Жергілікті желінің тұтастығын бұзу» сценарийін қарастыру жеткілікті.
Әдетте, төтенше жағдайлардың көпшілігі келесі түрлерге бөлінеді:
- Желі ақаулығы
- ОЖ қызметтерінің қатесі
- Қолданбаның сәтсіздігі
- Темірдің бұзылуы
- Виртуализация сәтсіздігі
Әр түрді қарап шығып, қызметіңізге не қолданылатынын көріңіз. Мысалы, Nginx демоны құлап, көтерілмеуі мүмкін - бұл ОЖ тарапынан сәтсіздіктерді білдіреді. Веб-бағдарламаның істен шығуына әкелетін сирек жағдай бағдарламалық құралдың ақаулығы болып табылады. Осы кезеңмен жұмыс істеу кезінде мәселенің диагнозын пысықтау маңызды. Виртуализациядағы қатып қалған интерфейсті құлаған cis дискісінен және желілік апаттан қалай ажыратуға болады, мысалы. Бұл жауапты адамдарды тез тауып, апат жойылмайынша олардың құйрығын тарта бастау маңызды.
Типтік мәселелер жазылғаннан кейін, біз көбірек кофе құйып, кейбір параметрлер нормадан әлдеқайда асып кеткен кезде ең оғаш сценарийлерді қарастыра бастаймыз. Мысалы:
- Белсенді түйіндегі уақыт кластердегі басқалармен салыстырғанда бір минутқа артқа жылжыса не болады?
- Уақыт алға жылжыса ше, 10 жыл болса ше?
- Синхрондау кезінде кластер түйіні кенеттен желіден айырылса не болады?
- Желіде бір-бірінің уақытша оқшаулануына байланысты екі түйін көшбасшылықты бөліспесе не болады?
Бұл кезеңде кері тәсіл өте пайдалы. Сіз команданың ең қыңыр мүшесін ауру қиялмен қабылдайсыз және оған қызметтің төмендеуіне әкелетін ең қысқа мерзімде диверсия ұйымдастыру тапсырмасын бересіз. Егер диагноз қою қиын болса, одан да жақсы. Егер сіз оларға бірдеңені бұзу идеясын берсеңіз, инженерлердің қандай оғаш және керемет идеяларды ойлап тапқанына сенбейсіз. Егер сіз оларға бұл үшін сынақ үстелін уәде етсеңіз, бұл өте жақсы.
Бұл сіздің ДРП дегеніңіз не?!
Сонымен, сіз қауіп үлгісін анықтадыңыз. Олар сондай-ақ мыс іздеп талшықты-оптикалық кабельдерді кескен жергілікті тұрғындарды және жұма күндері сағат 16:46-да радиорелейлік желіні түсіретін әскери радарды ескерді. Енді біз мұның бәрімен не істеу керектігін түсінуіміз керек.
Сіздің міндетіңіз - төтенше жағдайда ашылатын өте қызыл конверттерді жазу. Бірден күтіңіз (егер емес!) бәрі аяқталады, тек тәжірибесіз интерн жақын жерде болады, оның қолдары болып жатқан қорқыныштан қатты дірілдейді. Медициналық кеңселерде апат белгілерінің қалай жүзеге асырылатынын қараңыз. Мысалы, анафилактикалық шок кезінде не істеу керек. Медициналық персонал барлық хаттамаларды жатқа біледі, бірақ жақын маңдағы адам өле бастағанда, бәрі жиі көзге көрінетін нәрсені дәрменсіз ұстайды. Мұны істеу үшін қабырғада «осындай пакетті ашу» және «дәрінің көптеген бірлігін көктамырға енгізу» сияқты заттар жазылған нақты нұсқаулар бар.
Төтенше жағдайда ойлау қиын! Жұлынның талдауы бойынша қарапайым нұсқаулар болуы керек.
Жақсы DRP бірнеше қарапайым блоктардан тұрады:
- ЖКО басталғаны туралы кімге хабарлау керек. Бұл жою процесін мүмкіндігінше параллельдеу үшін маңызды.
- Диагнозды қалай дұрыс қою керек - ізді орындаңыз, systemctl күйінің қызмет атауын қараңыз және т.б.
- Әр кезеңге қанша уақыт жұмсай аласыз? SLA уақытында оны қолмен түзетуге уақытыңыз болмаса, виртуалды машина жойылып, кешегі сақтық көшірмеден кері қайтарылады.
- Апаттың аяқталғанына қалай көз жеткізуге болады.
Есіңізде болсын, DRP қызмет толығымен істен шыққан кезде басталып, қызмет қалпына келтірілгенде, тіпті тиімділігі төмендеген кезде аяқталады. Резервті жай ғана жоғалту DRP-ны тудырмауы керек. Сіз сондай-ақ DRP-ге бір кесе шай жаза аласыз. Шынайы. Статистикаға сәйкес, көптеген апаттар жағымсыздан апатқа айналады, себебі дүрбелеңдегі қызметкерлер бірдеңені түзетуге асығады, бір уақытта деректермен жалғыз тірі түйінді өлтіреді немесе кластерді аяқтайды. Әдетте, бір шыны шаймен 5 минут сізді тыныштандыруға және не болып жатқанын талдауға біраз уақыт береді.
DRP мен жүйе төлқұжатын шатастырмаңыз! Оны қажетсіз деректермен шамадан тыс жүктемеңіз. Құжаттаманың қажетті бөліміне өту және қызмет архитектурасының қажетті бөлімдері туралы кеңейтілген форматта оқу үшін гиперсілтемелерді жылдам және ыңғайлы пайдалануға мүмкіндік беріңіз. Ал DRP-нің өзінде көшіру-қоюға арналған нақты пәрмендерге қай жерде және қалай қосылуға болатыны туралы тікелей нұсқаулар ғана бар.
Қалай дұрыс тестілеу керек
Кез келген жауапты қызметкер барлық тармақтарды орындай алатынына көз жеткізіңіз. Ең маңызды сәтте инженердің қажетті жүйеге қол жеткізуге құқығы жоқ екендігі, қажетті тіркелгі үшін құпия сөздердің жоқтығы немесе «Қызметті басқару консоліне прокси арқылы қосылу» дегенді білмеуі мүмкін. бас кеңсе» дегенді білдіреді. Әрбір нүкте өте қарапайым болуы керек.
Қате - «Виртуализацияға өтіп, өлі түйінді қайта жүктеңіз»
Дұрыс - «Веб-интерфейс арқылы virt.example.com сайтына қосылыңыз, түйіндер бөлімінде қатені тудыратын түйінді қайта жүктеңіз.»
Екіжақтылықтан аулақ болыңыз. Қорыққан интернді еске түсіріңіз.
DRP тексеруді ұмытпаңыз. Бұл жай ғана шоу жоспары емес – бұл сізге және сіздің клиенттеріңізге қиын жағдайдан тез шығуға мүмкіндік беретін нәрсе. Мұны бірнеше рет жасаған дұрыс:
- Бір сарапшы және бірнеше тыңдаушы мүмкіндігінше шынайы қызметті имитациялайтын сынақ стендінде жұмыс істейді. Сарапшы қызметті әртүрлі жолдармен бұзады және тыңдаушыларға оны DRP бойынша қалпына келтіруге мүмкіндік береді. Барлық мәселелер, құжаттамадағы түсініксіздіктер мен қателер жазылады. Тыңдаушылар оқытылғаннан кейін DRP түсініксіз жерлерде кеңейтіліп, жеңілдетіледі.
- Нақты қызметте тестілеу. Шын мәнінде, сіз ешқашан нақты қызметтің тамаша көшірмесін жасай алмайсыз. Сондықтан, қалпына келтіру тәртібін бағалау үшін жылына бірнеше рет кейбір серверлерді жүйелі түрде өшіріп, қосылымдарды үзіп, қауіптер тізімінен басқа апаттар тудыруы керек. Түн ортасында 10 минутқа жоспарланған сәтсіздік деректердің жоғалуымен ең жоғары жүктеме кезінде бірнеше сағат бойы кенеттен істен шығудан жақсы.
- Нақты ақауларды жою. Иә, бұл да тестілеудің бір бөлігі. Қауіптер тізімінде болмаған жазатайым оқиға орын алса, оны тергеу нәтижелері бойынша ДРП толықтыру және пысықтау қажет.
Негізгі нүктелер
- Боқтық орын алуы мүмкін болса, бұл орын алып қана қоймайды, бірақ бұл мүмкін болатын ең апатты сценарийде болады.
- Төтенше жүктемені тасымалдау үшін ресурстарыңыз бар екеніне көз жеткізіңіз.
- Сақтық көшірмелердің бар екеніне көз жеткізіңіз, олар автоматты түрде жасалады және тұрақтылық үнемі тексеріледі.
- Типтік қауіп сценарийлері арқылы ойланыңыз.
- Инженерлерге қызмет көрсетудің стандартты емес нұсқаларын ұсынуға мүмкіндік беріңіз.
- DRP қарапайым және анық нұсқау болуы керек. Барлық кешенді диагностика клиенттерге қызмет көрсету қалпына келтірілгеннен кейін ғана жүргізіледі. Тіпті резервтік қуатта болса да.
- DRP-де негізгі телефон нөмірлері мен контактілерді көрсетіңіз.
- Қызметкерлердің DRP түсінігін үнемі тексеріп отырыңыз.
- Өндіріс орындарында жоспарланған жазатайым оқиғаларды ұйымдастыру. Стендтер бәрін алмастыра алмайды.
Ақпарат көзі: www.habr.com