Представьте себе: вы обслуживаете ИТ-инфраструктуру крупного торгового центра. В городе начинается ливень. Потоки дождя прорывают крышу, вода заполняет торговые помещения по щиколотку. Надеемся, что ваша серверная не в подвале, иначе проблем не избежать.
La priskribita rakonto ne estas fantazio, sed kolektiva priskribo de kelkaj eventoj de 2020. En grandaj kompanioj, katastrofa reakiro, aŭ katastrofa reakiro (DRP), ĉiam estas ĉe mano por ĉi tiu kazo. En korporacioj, ĉi tio estas respondeco de specialistoj pri komerca kontinueco. Sed en mezaj kaj malgrandaj kompanioj, solvi tiajn problemojn falas sur IT-servoj. Vi devas mem kompreni la komercan logikon, kompreni kio povas malsukcesi kaj kie, elpensi protekton kaj efektivigi ĝin.
Estas bonege se IT-specialisto povas negoci kun la komerco kaj diskuti la bezonon de protekto. Sed mi vidis pli ol unufoje, kiel kompanio ŝparis pri katastrofa reakiro (DR) solvo ĉar ĝi konsideris ĝin redunda. Kiam okazis akcidento, longa resaniĝo minacis perdojn, kaj la komerco ne estis preta. Vi povas ripeti kiom vi volas: "Mi diris tion al vi", sed la IT-servo ankoraŭ devos restarigi servojn.
De la pozicio de arkitekto, mi diros al vi kiel eviti ĉi tiun situacion. En la unua parto de la artikolo, mi montros la preparan laboron: kiel diskuti tri demandojn kun la kliento por elekti sekurecajn ilojn:
- Kion ni protektas?
- De kio ni protektas?
- Kiom ni protektas?
En la dua parto, ni parolos pri ebloj por respondi la demandon: kiel defendi vin. Mi donos ekzemplojn de kazoj pri kiel malsamaj klientoj konstruas sian protekton.
Kion ni protektas: identigi kritikajn komercajn funkciojn
Estas pli bone komenci prepariĝi diskutante la post-krizan agadplanon kun la komerca kliento. La ĉefa malfacilaĵo ĉi tie estas trovi komunan lingvon. La kliento kutime ne zorgas pri kiel funkcias la IT-solvo. Li zorgas ĉu la servo povas plenumi komercajn funkciojn kaj alporti monon. Ekzemple: se la retejo funkcias, sed la pagsistemo malfunkcias, ne estas enspezo de klientoj, kaj la "ekstremistoj" ankoraŭ estas IT-specialistoj.
IT-profesiulo povas havi malfacilaĵojn en tiaj intertraktadoj pro pluraj kialoj:
- La IT-servo ne plene komprenas la rolon de la informsistemo en komerco. Ekzemple, se ne ekzistas disponebla priskribo de komercaj procezoj aŭ travidebla komerca modelo.
- Ne la tuta procezo dependas de la IT-servo. Ekzemple, kiam parto de la laboro estas farita de entreprenistoj, kaj IT-specialistoj ne havas rektan influon sur ili.
Mi strukturus la konversacion tiel:
- Объясняем бизнесу, что аварии случаются со всеми, а на восстановление требуется время. Лучше всего — продемонстрировать ситуации, как это происходит и какие последствия возможны.
- Показываем, что от ИТ-службы зависит не все, но вы готовы помочь с планом действий в зоне вашей ответственности.
- Ni petas al la komerca kliento respondi: se la apokalipso okazas, kiu procezo devus esti restarigita unue? Kiu partoprenas en ĝi kaj kiel?
Simpla respondo estas postulata de la komerco, ekzemple: la telefoncentro devas daŭrigi registri aplikojn 24/7.
- Просим одного-двух пользователей системы подробно описать этот процесс.
Лучше привлечь на помощь аналитика, если в вашей компании такой есть.Komence, la priskribo povas aspekti jene: la telefoncentro ricevas petojn per telefono, per poŝto kaj per mesaĝoj de la retejo. Poste li enigas ilin en 1C per la retinterfaco, kaj produktado prenas ilin de tie tiamaniere.
- Затем смотрим, какие аппаратные и программные решения поддерживают процесс. Для комплексной защиты учитываем три уровня:
- aplikoj kaj sistemoj ene de la retejo (programara nivelo),
- la retejo mem kie la sistemoj funkcias (infrastruktura nivelo),
- сеть (про нее вообще часто забывают).
- Ni malkovras eblajn punktojn de fiasko: sistemaj nodoj, de kiuj dependas la agado de la servo. Ni aparte notas nodojn, kiuj estas subtenataj de aliaj kompanioj: telekomunikaj telefonistoj, gastigaj provizantoj, datumcentroj ktp. Kun ĉi tio, vi povas reveni al la komerca kliento por la sekva paŝo.
От чего защищаем: риски
Дальше выясняем у бизнес-заказчика, от каких рисков мы защищаемся в первую очередь. Все риски условно поделим на две группы:
- perdo de tempo pro servo malfunkcio;
- perdo de datumoj pro fizikaj efikoj, homaj faktoroj, ktp.
Komercoj timas perdi kaj datumojn kaj tempon - ĉio ĉi kondukas al perdo de mono. Do denove ni demandas por ĉiu riska grupo:
- Por ĉi tiu procezo, ĉu ni povas taksi kiom da datumperdo kaj tempoperdo kostas en mono?
- Kiajn datumojn ni ne povas perdi?
- Где не можем допустить простоя?
- Kiuj eventoj estas plej verŝajnaj kaj plej minacaj por ni?
Post diskuto, ni komprenos kiel prioritati malsukcesajn punktojn.
Kiom ni protektas: RPO kaj RTO
Когда понятны критические точки отказа, рассчитываем показатели RTO и RPO.
Mi memorigos vin RTO (reakira tempocelo) — ĉi tiu estas la permesebla tempo de la momento de la akcidento ĝis la servo estas plene restarigita. En komerca lingvo, ĉi tio estas akceptebla malfunkcio. Se ni scias kiom da mono la procezo alportis, ni povas kalkuli la perdojn de ĉiu minuto da malfunkcio kaj kalkuli la akcepteblan perdon.
RPO (reakira punkto objektivo) — допустимая точка восстановления данных. Она определяет время, за которое мы можем потерять данные. С точки зрения бизнеса, потеря данных может грозить, например, штрафами. Такие потери тоже можно перевести в деньги.
Время восстановления нужно рассчитывать для конечного пользователя: в какой срок он сможет войти в систему. Так что сначала складываем время восстановления всех звеньев цепи. Здесь часто делают ошибку: берут RTO провайдера из SLA, а про остальные слагаемые забывают.
Ni rigardu specifan ekzemplon. La uzanto ensalutas en 1C, la sistemo malfermiĝas kun datumbaza eraro. Li kontaktas la sistemadministranton. La datumbazo situas en la nubo, la administranto de la sistemo raportas la problemon al la provizanto de servoj. Ni diru, ke ĉiuj komunikadoj daŭras 15 minutojn. En la nubo, datumbazo de ĉi tiu grandeco estos restarigita de sekurkopio en horo, tial la RTO ĉe la servoprovizanto estas horo. Sed ĉi tio ne estas la fina limdato; por la uzanto, 15 minutoj estis aldonitaj al ĝi por detekti la problemon.
Poste, la sistemadministranto devas kontroli, ke la datumbazo estas ĝusta, konekti ĝin al 1C kaj komenci la servojn. Ĉi tio postulas alian horon, kio signifas, ke RTO flanke de la administranto jam estas 2 horoj kaj 15 minutoj. La uzanto bezonas pliajn 15 minutojn: ensalutu, kontrolu, ke la necesaj transakcioj aperis. 2 horoj 30 minutoj estas la tuta servo-reakiro en ĉi tiu ekzemplo.
Ĉi tiuj kalkuloj montros la komercon de kiuj eksteraj faktoroj dependas de la reakiro. Ekzemple, se la oficejo estas inundita, vi unue devas trovi la likon kaj ripari ĝin. Necesos tempo, kio ne dependas de IT.
Чем защищаем: выбираем инструменты для разных рисков
Post diskutado de ĉiuj punktoj, la kliento jam komprenas la koston de akcidento por la komerco. Nun vi povas elekti ilojn kaj diskuti la buĝeton. Uzante ekzemplojn de klientaj kazoj, mi montros al vi kiajn ilojn ni proponas por malsamaj taskoj.
Ni komencu per la unua grupo de riskoj: perdoj pro servomalfunkcio. Solvoj por ĉi tiu problemo devus provizi bonan RTO.
- Gastigu la aplikaĵon en la nubo
Komence, vi povas simple moviĝi al la nubo - la provizanto jam pripensis la problemojn de alta havebleco. Virtualigaj gastigantoj estas kunvenitaj en areton, potenco kaj reto estas rezervitaj, datumoj estas stokitaj sur mistoleremaj stokadsistemoj, kaj la provizanto de servoj finance respondecas pri malfunkcio.
Ekzemple, vi povas gastigi virtualan maŝinon kun datumbazo en la nubo. La aplikaĵo konektos al la datumbazo ekstere per establita kanalo aŭ de la sama nubo. Se problemoj aperas kun unu el la serviloj en la areto, la VM rekomencos sur la najbara servilo en malpli ol 2 minutoj. Post tio, la DBMS komenciĝos en ĝi, kaj post kelkaj minutoj la datumbazo estos disponebla.
OTR: mezurita en minutoj. Ĉi tiuj kondiĉoj povas esti specifitaj en la interkonsento kun la provizanto.
kosto de: считаем стоимость ресурсов облака под ваше приложение.
От чего не защитит: de amasaj malsukcesoj ĉe la provizanto, ekzemple, pro akcidentoj ĉe la urbonivelo. - Кластеризовать приложение
Se vi volas plibonigi RTO, vi povas plifortigi la antaŭan opcion kaj tuj meti grupigitan aplikaĵon en la nubon.
Реализовать кластер можно в режиме active-passive или active-active. Создаем несколько ВМ, исходя из требований вендора. Для большей надежности разносим их по разным серверам и СХД. При отказе сервера с одной из БД, резервная нода принимает на себя нагрузку за несколько секунд.
OTR: Mezurita en sekundoj.
kosto de: iomete pli multekosta ol regula nubo, aldonaj rimedoj estos postulataj por amasiĝo.
От чего не защитит: Ankoraŭ ne protektos kontraŭ amasaj surlokaj misfunkciadoj. Sed lokaj interrompoj ne daŭros tiel longe.De praktiko: La podetala kompanio havis plurajn informsistemojn kaj retejojn. Ĉiuj datumbazoj situis loke en la oficejo de la firmao. Oni pensis pri neniu DR ĝis la oficejo restis sen potenco plurfoje sinsekve. Klientoj estis malfeliĉaj pri retejaj kraŝoj.
Проблема с доступностью сервисов решилась после переезда в облако. Плюс к этому удалось оптимизировать нагрузку на базы данных за счет балансировки трафика между узлами. - Movu al katastrofa nubo
Se vi bezonas certigi, ke eĉ natura katastrofo en la ĉefa retejo ne malhelpas vian laboron, vi povas elekti katastrof-rezistan nubon.En ĉi tiu opcio, la provizanto disvastigas la virtualigan areton tra 2 datumcentroj. Konstanta sinkrona reproduktado okazas inter datencentroj, unu-al-unu. La kanaloj inter datumcentroj estas rezervitaj kaj iras laŭ malsamaj vojoj, do tia areto ne timas retajn problemojn.
OTR: tendencas al 0.
kosto de: La plej multekosta nuba opcio.
От чего не защитит: Ĝi ne helpos kontraŭ datuma korupto, same kiel de la homa faktoro, do rekomendas fari sekurkopiojn samtempe.De praktiko: Unu el niaj klientoj evoluigis ampleksan katastrofan reakiro-planon. Jen la strategio, kiun li elektis:
- Katastro-tolerema nubo protektas la aplikaĵon kontraŭ misfunkciadoj ĉe la infrastruktura nivelo.
- Dunivela sekurkopio provizas protekton en kazo de homa eraro. Estas du specoj de sekurkopioj: "malvarma" kaj "varma". "Malvarma" sekurkopio estas en malfunkciigita stato kaj bezonas tempon por deploji. "Varma" sekurkopio jam estas preta por uzo kaj estas restarigita pli rapide. Ĝi estas stokita sur speciale dediĉita stokadosistemo. La tria kopio estas registrita sur sonbendo kaj stokita en alia ĉambro.
Unufoje semajne, la kliento testas la protekton kaj kontrolas la funkciojn de ĉiuj sekurkopioj, inkluzive de tiuj de bendo. Ĉiujare la kompanio testas la tutan katastrof-rezistan nubon.
- Организовать репликацию на другую площадку
Alia eblo pri kiel eviti tutmondajn problemojn en la ĉefa retejo: provizi georezervadon. Alivorte, kreu rezervajn virtualajn maŝinojn ĉe loko en alia urbo. Specialaj solvoj por DR taŭgas por ĉi tio: en nia kompanio ni uzas VMware vCloud Availability (vCAV). Kun ĝia helpo, vi povas agordi protekton inter pluraj nubaj provizantaj retejoj aŭ restarigi al la nubo de surloka retejo. Mi jam parolis pli detale pri la skemo por labori kun vCAV .
RPO kaj RTO: ekde 5 minutoj.
kosto de: дороже первого варианта, но дешевле, чем аппаратная репликация в катастрофоустойчивом облаке. Цена складывается из стоимости лицензии vCAV, платы за администрирование, стоимости ресурсов облака и ресурсов под резерв по модели PAYG (10% от стоимости работающих ресурсов за выключенные ВМ).
De praktiko: Клиент держал в нашем облаке в Москве 6 виртуальных машин с разными базами данных. Сначала защиту обеспечивал бэкап: часть резервных копий хранили в облаке в Москве, часть — на нашей петербургской площадке. Со временем базы данных выросли в объеме, и восстановление из бэкапа стало требовать больше времени.
Reproduktado bazita sur VMware vCloud Availability estis aldonita al sekurkopioj. Kopioj de virtualaj maŝinoj estas konservitaj en rezerva retejo en Sankt-Peterburgo kaj estas ĝisdatigitaj ĉiujn 5 minutojn. Se fiasko okazas ĉe la ĉefa retejo, dungitoj sendepende ŝanĝas al kopio de la virtuala maŝino en Sankt-Peterburgo kaj daŭre laboras kun ĝi.
Ĉiuj konsiderataj solvoj provizas altan haveblecon, sed ne protektas kontraŭ datumperdo pro ransomware viruso aŭ hazarda dungita eraro. En ĉi tiu kazo, ni bezonos sekurkopiojn kiuj provizos la postulatan RPO.
5. Ne forgesu pri sekurkopio
Ĉiuj scias, ke vi devas fari sekurkopiojn, eĉ se vi havas la plej bonegan kontraŭkatastrofan solvon. Do mi nur mallonge memorigos vin pri kelkaj punktoj.
Strikte parolante, sekurkopio ne estas DR. Kaj tial:
- Estas longa tempo. Se la datumoj estas mezuritaj en terabajtoj, reakiro daŭros pli ol unu horon. Vi devas restarigi, atribui reton, kontroli ke ĝi ŝaltas, vidi ke la datumoj estas en ordo. Do vi povas provizi bonan RTO nur se estas malmulte da datumoj.
- La datumoj eble ne estas restarigitaj la unuan fojon, kaj vi devas permesi tempon por ripeti la agon. Ekzemple, estas tempoj kiam ni ne scias ĝuste kiam datumoj estis perditaj. Ni diru, ke la perdo estis rimarkita je 15.00, kaj kopioj estas faritaj ĉiuhore. Ekde 15.00 ni rigardas ĉiujn resanpunktojn: 14:00, 13:00 kaj tiel plu. Se la sistemo estas grava, ni provas minimumigi la aĝon de la reakiro. Sed se la freŝa sekurkopio ne enhavis la necesajn datumojn, ni prenas la sekvan punkton - ĉi tio estas plia tempo.
En ĉi tiu kazo, la rezerva horaro povas provizi la bezonatan RPO. Por sekurkopioj, estas grave provizi geo-rezervadon en kazo de problemoj kun la ĉefa retejo. Oni rekomendas konservi kelkajn rezervajn kopiojn aparte.
La fina katastrofa reakiro devas enhavi almenaŭ 2 ilojn:
- Unu el ebloj 1-4, kiu protektos sistemojn kontraŭ misfunkciadoj kaj faloj.
- Rezerva por protekti datumojn kontraŭ perdo.
Ankaŭ indas zorgi pri rezerva komunika kanalo, se la ĉefa interreta provizanto malsukcesos. Kaj — voila! — DR ĉe minimumaj salajroj jam pretas.
fonto: www.habr.com