Бүгінгі күні Bitrix24 қызметінде жүздеген гигабит трафик жоқ, сондай-ақ оның үлкен серверлер паркі де жоқ (бірақ, әрине, барлары өте аз). Бірақ көптеген клиенттер үшін бұл компанияда жұмыс істеудің негізгі құралы, бұл бизнес үшін маңызды қолданба. Сондықтан, құлап кетуге жол жоқ. Егер апат орын алса, бірақ қызмет ешкім ештеңе байқамағандай тез «қалпына келтірілсе» ше? Ал жұмыс сапасы мен клиенттердің санын жоғалтпай ауыстырып қосуды қалай жүзеге асыруға болады? Bitrix24 бұлтты қызметтерінің директоры Александр Демидов біздің блогқа өнімнің 7 жыл ішінде брондау жүйесінің қалай дамығаны туралы айтты.
«Біз Bitrix24-ті SaaS ретінде 7 жыл бұрын іске қостық. Негізгі қиындық келесіде болса керек: ол SaaS ретінде көпшілікке шығарылғанға дейін бұл өнім жәй ғана қорапты шешім форматында болған. Клиенттер оны бізден сатып алды, оны өз серверлерінде орналастырды, корпоративтік порталды құрды - қызметкерлердің байланысы, файлдарды сақтау, тапсырмаларды басқару, CRM үшін жалпы шешім. Ал 2012 жылға қарай біз оны SaaS ретінде іске қосқымыз келеді деп шештік, оны өзіміз басқарамыз, ақауларға төзімділік пен сенімділікті қамтамасыз етеміз. Біз осы жолда тәжірибе жинадық, өйткені оған дейін бізде бұл жай ғана болған жоқ – біз тек бағдарламалық қамтамасыз етуді өндірушілер едік, қызмет көрсетушілер емес едік.
Қызметті іске қосқан кезде біз ең бастысы ақауларға төзімділікті, қызметтің сенімділігін және тұрақты қолжетімділігін қамтамасыз ету екенін түсіндік, өйткені сізде қарапайым қарапайым веб-сайт, мысалы, дүкен болса және ол сізге түсіп, сол жерде отырады. бір сағат, тек сіз зардап шегесіз, тапсырыстарды жоғалтасыз, клиенттерді жоғалтасыз, бірақ сіздің клиентіңіз үшін бұл ол үшін өте маңызды емес. Ол, әрине, ренжіді, бірақ ол басқа сайттан барып сатып алды. Ал егер бұл компаниядағы барлық жұмыс, коммуникациялар, шешімдер байланыстырылған қолданба болса, онда ең бастысы - пайдаланушылардың сеніміне ие болу, яғни оларды жерге түсірмеу және құлап қалмау. Өйткені ішіндегі бірдеңе жұмыс істемесе, барлық жұмыс тоқтап қалуы мүмкін.
SaaS ретінде Bitrix.24
Біз бірінші прототипті көпшілікке шығарылымнан бір жыл бұрын, 2011 жылы құрастырдық. Біз оны шамамен бір аптаның ішінде жинадық, қарадық, айналдырдық - ол тіпті жұмыс істеп тұрды. Яғни, пішінге кіріп, сол жерге порталдың атын енгізе аласыз, жаңа портал ашылады және пайдаланушы базасы құрылады. Біз оны қарап шықтық, өнімді принципті түрде бағалап, оны тастап, оны бір жыл бойы нақтылауды жалғастырдық. Өйткені бізде үлкен міндет тұрды: біз екі түрлі код негізін жасағымыз келмеді, біз бөлек оралған өнімді, бөлек бұлттық шешімдерді қолдағымыз келмеді - біз мұның барлығын бір код ішінде жасағымыз келді.
Сол кездегі әдеттегі веб-бағдарлама кейбір PHP коды жұмыс істейтін бір сервер болды, MySQL дерекқоры, файлдар жүктеледі, құжаттар, суреттер жүктеу қалтасына қойылады - бәрі де жұмыс істейді. Өкінішке орай, мұны пайдаланып сыни тұрақты веб-қызметті іске қосу мүмкін емес. Онда таратылған кэшке қолдау көрсетілмейді, дерекқорды репликациялауға қолдау көрсетілмейді.
Біз талаптарды тұжырымдадық: бұл әртүрлі орындарда орналасу, репликацияны қолдау және әр түрлі географиялық таралған деректер орталықтарында орналасу мүмкіндігі. Өнім логикасын және шын мәнінде деректерді сақтауды бөліңіз. Жүктемеге сәйкес динамикалық масштабтауға және статикаға толығымен шыдай білу. Осы ойлардан, шын мәнінде, өнімге қойылатын талаптар пайда болды, біз оны жыл бойы нақтыладық. Осы уақыт ішінде біртұтас болып шыққан платформада - қорапты шешімдер үшін, өз қызметіміз үшін - біз қажет нәрселерге қолдау көрсеттік. Өнімнің өзі деңгейінде MySQL репликациясын қолдау: яғни кодты жазған әзірлеуші өзінің сұраулары қалай таратылатыны туралы ойламайды, ол біздің api-ны пайдаланады және біз шеберлер арасында жазу және оқу сұраныстарын қалай дұрыс бөлу керектігін білеміз. және құлдар.
Біз әртүрлі бұлттық нысандар қоймалары үшін өнім деңгейінде қолдау көрсеттік: google қоймасы, amazon s3, сонымен қатар ашық стек жылдам қолдауы. Сондықтан, бұл бізге қызмет ретінде де, пакеттік шешіммен жұмыс істейтін әзірлеушілер үшін де ыңғайлы болды: егер олар тек жұмыс үшін біздің API-ді пайдаланса, олар файлдың қай жерде, файлдық жүйеде немесе жергілікті түрде сақталатынын ойламайды. объектінің файл қоймасында.
Нәтижесінде біз бірден бүкіл деректер орталығының деңгейінде резервтеуді шештік. 2012 жылы біз толығымен Amazon AWS жүйесінде іске қостық, себебі бұл платформамен тәжірибеміз бұрыннан болған - біздің жеке веб-сайт сонда орналастырылған. Бізді әр аймақта Amazon-да бірнеше қолжетімділік аймақтары бар екендігі қызықтырды - шын мәнінде (олардың терминологиясында) бір-бірінен азды-көпті тәуелсіз және бүкіл деректер орталығы деңгейінде резервтеуге мүмкіндік беретін бірнеше деректер орталықтары: егер ол кенеттен істен шықса, дерекқорлар master-master репликацияланады, веб-бағдарлама серверлерінің сақтық көшірмесі жасалады және статикалық деректер s3 нысан жадына жылжытылады. Жүктеме теңдестірілген - ол кезде Amazon elb арқылы, бірақ сәл кейінірек біз өзіміздің жүк теңестірушілерге келдік, өйткені бізге күрделі логика қажет болды.
Олардың қалағандары - қолдары болды ...
Біз қамтамасыз еткіміз келетін барлық негізгі нәрселер - серверлердің қателеріне төзімділік, веб-қосымшалар, дерекқорлар - бәрі жақсы жұмыс істеді. Ең қарапайым сценарий: егер біздің веб-қосымшаларымыздың бірі сәтсіз болса, онда бәрі қарапайым - олар теңгерімнен ажыратылады.
Теңгерімші (ол кезде бұл Amazon-ның қолы болатын) істен шыққан машиналарды сау емес деп белгілеп, олардағы жүктемені бөлуді өшірді. Amazon автомасштабтауы жұмыс істеді: жүктеме өскен кезде автомасштабтау тобына жаңа машиналар қосылды, жүктеме жаңа машиналарға таратылды - бәрі жақсы болды. Біздің теңгерімдеушілерде логика шамамен бірдей: егер қолданба серверіне бірдеңе болса, біз одан сұрауларды алып тастаймыз, бұл машиналарды лақтырып тастаймыз, жаңаларын іске қосамыз және жұмысын жалғастырамыз. Схема жылдар бойы аздап өзгерді, бірақ жұмысын жалғастыруда: бұл қарапайым, түсінікті және онымен ешқандай қиындықтар жоқ.
Біз бүкіл әлемде жұмыс істейміз, тұтынушылардың ең жоғары жүктемелері мүлдем басқаша, және қолайлы жолмен біз жүйеміздің кез келген құрамдас бөліктеріне кез келген уақытта - тұтынушылар байқамай-ақ белгілі бір қызмет көрсету жұмыстарын орындай алуымыз керек. Сондықтан, бізде екінші деректер орталығына жүктемені қайта бөле отырып, дерекқорды жұмыстан өшіруге мүмкіндігіміз бар.
Мұның бәрі қалай жұмыс істейді? — Біз трафикті жұмыс істейтін дата орталығына ауыстырамыз - егер дата орталығында апат болса, онда толықтай, егер бұл біздің бір дерекқормен жоспарланған жұмысымыз болса, онда біз осы клиенттерге қызмет көрсететін трафиктің бір бөлігін екінші деректер орталығына ауыстырамыз, тоқтатамыз. оның қайталануы. Екінші деректер орталығына жүктеме артқандықтан, веб-қосымшалар үшін жаңа машиналар қажет болса, олар автоматты түрде іске қосылады. Біз жұмысты аяқтаймыз, репликация қалпына келтірілді және біз бүкіл жүктемені қайтарамыз. Екінші ДК-де кейбір жұмыстарды көрсету қажет болса, мысалы, жүйе жаңартуларын орнату немесе екінші дерекқордағы параметрлерді өзгерту, жалпы алғанда, біз дәл сол нәрсені басқа бағытта қайталаймыз. Ал егер бұл апат болса, онда біз бәрін тривиальды түрде жасаймыз: біз мониторинг жүйесінде оқиғаларды өңдеу механизмін қолданамыз. Егер бірнеше тексерулер іске қосылса және күй критикалық күйге ауысса, онда біз осы өңдегішті, осы немесе басқа логиканы орындай алатын өңдегішті іске қосамыз. Әрбір дерекқор үшін біз оның қай сервері ауыстырылатынын және ол қолжетімді болмаса, трафикті қайда ауыстыру керектігін анықтаймыз. Тарихи түрде біз нагиосты немесе оның кейбір шанышқыларын бір немесе басқа түрде қолданамыз. Негізінде, ұқсас механизмдер кез келген дерлік бақылау жүйесінде бар, біз әзірге күрделірек ештеңе қолданбаймыз, бірақ бір күні біз қолданатын шығармыз. Енді мониторинг қол жетімсіздігінен басталады және бір нәрсені ауыстыру мүмкіндігіне ие.
Біз бәрін брондадық па?
Бізде АҚШ-тан көптеген клиенттер, Еуропадан көптеген клиенттер, Шығысқа жақын көптеген клиенттер - Жапония, Сингапур және т.б. Әрине, клиенттердің үлкен үлесі Ресейде. Яғни, жұмыс бір аймақта емес. Пайдаланушылар жылдам жауап алғысы келеді, әртүрлі жергілікті заңдарды сақтау талаптары бар және әр аймақта біз екі дата орталығын сақтаймыз, сонымен қатар бірнеше қосымша қызметтер бар, олар қайтадан бір аймақта орналастыруға ыңғайлы - бұл жерде орналасқан клиенттер үшін бұл аймақ жұмыс істейді. REST өңдеушілері, авторизация серверлері, олар тұтастай клиенттің жұмысы үшін аса маңызды емес, сіз олардан кішкене қолайлы кідіріспен ауыса аласыз, бірақ сіз оларды бақылау және не істеу керектігі туралы дөңгелекті қайта ойлап тапқыңыз келмейді. олармен бірге. Сондықтан біз қосымша өнімдерде қандай да бір құзыретті дамытпай, бар шешімдерді барынша пайдалануға тырысамыз. Бір жерде біз DNS деңгейінде ауысуды тривиальды түрде қолданамыз және сол DNS арқылы қызметтің жандылығын анықтаймыз. Amazon-да Route 53 қызметі бар, бірақ бұл жай ғана жазбалар жасауға болатын DNS емес, сонымен қатар ол әлдеқайда икемді және ыңғайлы. Ол арқылы геолокациялары бар гео-таратылған қызметтерді құруға болады, оны клиенттің қайдан келгенін анықтау және оған белгілі бір жазбаларды беру үшін пайдаланған кезде - оның көмегімен ауыстырып-қосқыш архитектураларды құруға болады. Дәл осындай денсаулық тексерулері 53-маршруттың өзінде конфигурацияланған, сіз бақыланатын соңғы нүктелерді орнатасыз, көрсеткіштерді орнатасыз, қызметтің «тіршілігін» анықтау үшін қандай протоколдарды орнатасыз - tcp, http, https; қызметтің тірі немесе жоқтығын анықтайтын тексеру жиілігін орнату. Ал DNS-тің өзінде ненің негізгі, ненің қосымша болатынын, 53-ші маршруттың ішінде денсаулықты тексеру іске қосылса, қайда ауысу керектігін көрсетесіз. Мұның бәрін басқа құралдармен жасауға болады, бірақ бұл неге ыңғайлы - біз оны орнаттық. бір рет жоғарылатыңыз, содан кейін бұл туралы мүлде ойламаңыз, біз қалай тексереміз, қалай ауыстырамыз: бәрі өздігінен жұмыс істейді.
Бірінші «бірақ»: 53 маршруттың өзін қалай және немен брондауға болады? Кім біледі, оған бірдеңе болса ше? Бақытымызға орай, біз бұл тырмаға ешқашан баспадық, бірақ менде неге әлі де брондау керек деп ойлағанымыз туралы әңгіме болады. Мұнда біз алдын ала өзімізге сабан төседік. Күніне бірнеше рет біз 53-маршруттағы барлық аймақтарды толығымен түсіреміз. Amazon API оларды JSON форматында оңай жіберуге мүмкіндік береді және бізде оны түрлендіретін, конфигурациялар түрінде жүктеп салатын және шамамен алғанда сақтық көшірме конфигурациясы бар бірнеше резервтік серверлер бар. Егер бірдеңе орын алса, DNS параметрлерінің деректерін жоғалтпай оны қолмен жылдам орналастыра аламыз.
Екінші «бірақ»: Бұл суретте не әлі сақталмаған? Баланстың өзі! Біздің клиенттерді аймақтар бойынша бөлу өте қарапайым. Бізде bitrix24.ru, bitrix24.com, .de домендері бар - қазір әртүрлі аймақтарда жұмыс істейтін 13 түрлі домендер бар. Біз мынаған келдік: әр аймақтың өз теңгерімдері бар. Бұл желідегі ең жоғары жүктеме қай жерде болатынына байланысты аймақтар бойынша таратуды ыңғайлы етеді. Егер бұл бір теңгерімдегі ақаулық болса, ол жай ғана қызметтен шығарылады және DNS-ден жойылады. Балансерлер тобында қандай да бір мәселе туындаса, онда олардың сақтық көшірмесі басқа тораптарда жасалады және олардың арасында ауысу сол маршрут арқылы жүзеге асырылады53, себебі қысқа TTL болғандықтан, ауысу ең көбі 2, 3, 5 минут ішінде жүреді. .
Үшінші «бірақ»: Не әлі сақталмаған? S3, дұрыс. Біз пайдаланушылар үшін сақтайтын файлдарды s3 жүйесіне орналастырған кезде, біз оның қару-жарақ тесетініне шын жүректен сендік және онда ештеңені сақтаудың қажеті жоқ. Бірақ тарих басқаша болатынын көрсетеді. Жалпы алғанда, Amazon S3-ті іргелі қызмет ретінде сипаттайды, өйткені Amazon өзі S3-ті машиналық кескіндерді, конфигурацияларды, AMI кескіндерін, лездік суреттерді сақтау үшін пайдаланады... Ал егер біз пайдаланып келе жатқан 3 жыл ішінде бір рет болған s7 бұзылса. bitrix24, ол оны желдеткіш сияқты бақылайды. Көптеген нәрселер пайда болады - виртуалды машиналарды іске қосу мүмкін емес, api сәтсіздігі және т.б.
Ал S3 құлауы мүмкін - бұл бір рет болды. Сондықтан біз келесі схемаға келдік: бірнеше жыл бұрын Ресейде маңызды қоғамдық объектілерді сақтау қоймалары болған жоқ және біз өзімізше бірдеңе жасау мүмкіндігін қарастырдық... Бақытымызға орай, біз мұны бастамадық, өйткені біз бізде жоқ сараптаманы қазып алды және шатастыруы мүмкін. Қазір Mail.ru-да s3-үйлесімді жады бар, Яндексте және басқа да бірқатар провайдерлерде бар. Ақырында біз біріншіден, сақтық көшірме жасауды, екіншіден, жергілікті көшірмелермен жұмыс істеу мүмкіндігін алғымыз келеді деген ойға келдік. Ресей аймағы үшін біз s3 интерфейсімен үйлесімді API болып табылатын Mail.ru Hotbox қызметін қолданамыз. Қолданбаның ішіндегі кодқа ешқандай негізгі өзгертулер қажет болмады және біз келесі механизмді жасадық: s3-де нысандарды құру/жоюды іске қосатын триггерлер бар, Amazon-да Lambda деп аталатын сервис бар - бұл кодты серверсіз іске қосу. ол белгілі бір триггерлер іске қосылғанда ғана орындалады.
Біз мұны өте қарапайым жасадық: егер триггер іске қосылса, нысанды Mail.ru қоймасына көшіретін кодты орындаймыз. Деректердің жергілікті көшірмелерімен жұмысты толығымен бастау үшін ресейлік сегменттегі клиенттер оларға жақынырақ жадпен жұмыс істей алатындай кері синхрондау қажет. Пошта өзінің жадындағы триггерлерді аяқтағалы жатыр - инфрақұрылым деңгейінде кері синхрондауды орындау мүмкін болады, бірақ қазір біз мұны өз кодымыздың деңгейінде жасаймыз. Егер клиент файлды орналастырғанын көрсек, онда код деңгейінде оқиғаны кезекке қоямыз, оны өңдейміз және кері репликация жасаймыз. Неліктен бұл жаман: егер біз өз өнімдерімізден тыс, яғни қандай да бір сыртқы құралдармен жұмыс жасасақ, біз оны ескермейміз. Сондықтан, біз кодты қай жерден орындасақ та, бізге келген нысан басқа бағытта көшірілетін етіп сақтау деңгейінде триггерлер пайда болғанша соңына дейін күтеміз.
Код деңгейінде біз әрбір клиент үшін екі сақтау орнын да тіркейміз: біреуі негізгі болып саналады, екіншісі резервтік болып саналады. Егер бәрі жақсы болса, біз өзімізге жақынырақ қоймамен жұмыс істейміз: яғни Amazon-да орналасқан клиенттеріміз S3-пен жұмыс істейді, ал Ресейде жұмыс істейтіндер Hotbox-пен жұмыс істейді. Егер жалауша іске қосылса, ауыстырып қосу қосылуы керек және біз клиенттерді басқа жадқа ауыстырамыз. Біз бұл ұяшықты аймақ бойынша тәуелсіз белгілей аламыз және оларды алға және артқа ауыстыра аламыз. Біз мұны әлі іс жүзінде қолданған жоқпыз, бірақ біз бұл механизмді қарастырдық және бір күні бізге дәл осы қосқыш қажет болады және пайдалы болады деп ойлаймыз. Бұл бір рет болды.
О, және Amazon қашып кетті ...
Биыл сәуірде Ресейде Telegram-ды бұғаттаудың басталғанына бір жыл толады. Ең көп зардап шеккен провайдер - Amazon. Ал, өкінішке орай, бүкіл әлем үшін жұмыс істеген ресейлік компаниялар көбірек зардап шекті.
Егер компания жаһандық болса және Ресей ол үшін өте кішкентай сегмент болса, 3-5% - жақсы, бір жолмен немесе басқаша, сіз оларды құрбан ете аласыз.
Егер бұл таза ресейлік компания болса - мен оны жергілікті жерде орналастыру керек екеніне сенімдімін - бұл жай ғана пайдаланушылардың өздері үшін ыңғайлы, ыңғайлы болады және тәуекелдер аз болады.
Бұл жаһандық деңгейде жұмыс істейтін және Ресейден және әлемнің кез келген жерінен шамамен бірдей клиенттер саны бар компания болса ше? Сегменттердің байланысы маңызды және олар бір-бірімен қандай да бір жолмен жұмыс істеуі керек.
2018 жылдың наурыз айының соңында Роскомнадзор ірі операторларға Zello мессенджерін бұғаттау үшін бірнеше миллион Amazon IP мекенжайын бұғаттауды жоспарлап отырғаны туралы хат жолдады. Дәл осы провайдерлердің арқасында олар хатты барлығына сәтті таратып жіберді және Amazon-пен байланыс үзілуі мүмкін деген түсінік болды. Бұл жұма еді, біз серверs.ru сайтындағы әріптестерімізге: «Достар, бізге Ресейде емес, Амазонка емес, мысалы, Амстердамның бір жерінде орналасатын бірнеше серверлер керек» деп жүгірдік. Кем дегенде қандай да бір жолмен біз әсер ете алмайтын кейбір соңғы нүктелер үшін өз VPN және проксиді орнату мүмкіндігін алу үшін, мысалы, бірдей s3 соңғы нүктелері - біз жаңа қызметті көтеруге және басқа IP алуға әрекет жасай алмаймыз, бізге әлі де жету керек. Бірнеше күннің ішінде біз бұл серверлерді орнаттық, оларды іске қостық және тұтастай алғанда блоктау басталған сәтке дайындалдық. Бір қызығы, РКН шу мен дүрбелеңге қарап: «Жоқ, біз қазір ештеңені бұғаттамаймыз» деді. (Бірақ бұл дәл Telegram бұғаттау басталғанға дейін.) Айналма мүмкіндіктерді орнатып, бұғаттау енгізілмегенін түсінгендіктен, біз барлық мәселені шешуге кіріспедік. Иә, тек жағдайда.
Ал 2019 жылы біз әлі де бұғаттау жағдайында өмір сүріп жатырмыз. Мен кеше түнде қарадым: миллионға жуық IP бұғатталуын жалғастыруда. Рас, Amazon толығымен дерлік бұғаттан шығарылды, оның шыңында ол 20 миллион адреске жетті... Жалпы, нақтылық, үйлесімділік, жақсы үйлесімділік болмауы мүмкін. Кенеттен. Ол техникалық себептерге байланысты болмауы мүмкін - өрт, экскаваторлар, бәрі. Немесе, біз көргеніміздей, толығымен техникалық емес. Сондықтан, үлкен және үлкен біреу, өзінің АС-сы бар, мұны басқа жолдармен басқара алады - тікелей қосылу және басқа нәрселер қазірдің өзінде l2 деңгейінде. Бірақ қарапайым нұсқада, біздікі сияқты немесе одан да кішірек, сізде басқа жерде көтерілген, алдын ала VPN, прокси конфигурацияланған серверлер деңгейінде резервтік болуы мүмкін, конфигурацияны сол сегменттерде оларға жылдам ауыстыру мүмкіндігі бар. бұл сіздің байланысыңыз үшін маңызды. Бұл Amazon блоктауы басталған кезде бізге бірнеше рет пайдалы болды; ең нашар жағдайда, біз олар арқылы тек S3 трафикіне рұқсат бердік, бірақ бірте-бірте мұның бәрі шешілді.
Бүкіл провайдерді... қалай брондауға болады?
Дәл қазір бізде бүкіл Amazon құлдырайтын сценарий жоқ. Бізде Ресей үшін де осындай сценарий бар. Ресейде бізді бір провайдер орналастырды, оның ішінен біз бірнеше сайтты таңдадық. Бір жыл бұрын біз мәселеге тап болдық: бұл екі деректер орталығы болса да, провайдердің желі конфигурациясының деңгейінде проблемалар болуы мүмкін, олар екі деректер орталықтарына да әсер етеді. Және біз екі сайтта да қолжетімсіз болуымыз мүмкін. Әрине, солай болды. Ішіндегі архитектураны қайта қарастырдық. Бұл айтарлықтай өзгерген жоқ, бірақ Ресей үшін қазір бізде бір провайдерден емес, екі түрлі сайттан екі сайт бар. Егер біреуі сәтсіз болса, біз екіншісіне ауыса аламыз.
Гипотетикалық түрде Amazon үшін біз басқа провайдер деңгейінде брондау мүмкіндігін қарастырамыз; мүмкін Google, мүмкін басқа біреу... Бірақ осы уақытқа дейін біз тәжірибе жүзінде Amazon-да бір қолжетімділік аймағы деңгейінде апаттар болғанымен, тұтас бір аймақ деңгейінде апаттар өте сирек кездесетінін байқадық. Сондықтан, бізде теориялық түрде «Амазонка - бұл Amazon емес» брондауын жасай аламыз деген ой бар, бірақ іс жүзінде бұл әлі олай емес.
Автоматтандыру туралы бірнеше сөз
Автоматтандыру әрқашан қажет пе? Бұл жерде Даннинг-Крюгер эффектісін еске түсіру орынды. «Х» осінде біздің алған біліміміз бен тәжірибеміз, ал «y» осінде біздің іс-әрекетімізге деген сенімділік. Басында біз ештеңе білмейміз және мүлде сенімді емеспіз. Содан кейін біз аздап білеміз және өзімізге сенімді боламыз - бұл «ақымақтық шыңы» деп аталатын, «деменция және батылдық» суретімен жақсы суреттелген. Содан кейін біз аздап үйрендік және шайқасқа шығуға дайынбыз. Содан кейін біз үлкен қателіктер жібереміз және біз бір нәрсені білетін сияқтымыз, бірақ іс жүзінде біз көп нәрсені білмейміз. Содан тәжірибе жинақтаған сайын өзімізге сенімді боламыз.
Белгілі бір апаттарға әртүрлі автоматты ауысулар туралы біздің логика осы графикте өте жақсы сипатталған. Біз бастадық - біз ештеңе істеуді білмедік, барлық дерлік жұмыс қолмен жасалды. Содан кейін біз бәріне автоматтандыруды қосып, тыныш ұйықтай алатынымызды түсіндік. Біз кенеттен мегарейкке қадам бастық: жалған позитив іске қосылды және біз трафикті алға-артқа ауыстырамыз, егер біз мұны істемеуіміз керек еді. Демек, репликация бұзылады немесе басқа нәрсе - бұл үмітсіздік аңғары. Содан кейін біз бәріне ақылмен қарау керек екенін түсінеміз. Яғни, жалған дабыл беру мүмкіндігін қамтамасыз ететін автоматтандыруға сену мағынасы бар. Бірақ! салдары жойқын болуы мүмкін болса, оны кезекші ауысымға, апаттың шынымен болғанына көз жеткізіп, қадағалап, қажетті әрекеттерді қолмен орындайтын кезекші инженерлерге тапсырған дұрыс...
қорытынды
7 жыл ішінде біз бірдеңе құлаған кезде дүрбелең болатынынан, проблемалар жоқ, тек міндеттер бар, оларды шешу керек және шешуге болатынын түсінуге көштік. Қызметті құру кезінде оған жоғарыдан қараңыз, орын алуы мүмкін барлық тәуекелдерді бағалаңыз. Егер сіз оларды бірден көрсеңіз, онда алдын ала резервтеуді және ақауларға төзімді инфрақұрылымды құру мүмкіндігін қамтамасыз етіңіз, өйткені істен шығуы мүмкін және қызметтің жұмыс істемеуіне әкелетін кез келген нүкте мұны міндетті түрде жасайды. Тіпті сізге инфрақұрылымның кейбір элементтері міндетті түрде сәтсіздікке ұшырамайтын сияқты көрінсе де - дәл сол s3 сияқты, олар мүмкін екенін есте сақтаңыз. Кем дегенде, теориялық тұрғыдан, егер бірдеңе болса, олармен не істейтінін біліңіз. Тәуекелдерді басқару жоспары бар. Барлығын автоматты түрде немесе қолмен жасауды ойласаңыз, тәуекелдерді бағалаңыз: автоматика бәрін ауыстыра бастаса не болады - бұл апатпен салыстырғанда одан да нашар жағдайға әкелмей ме? Мүмкін, бір жерде автоматтандыруды қолдану мен нақты суретті бағалайтын және бір нәрсені орнында ауыстыру керек пе, әлде «иә, бірақ қазір емес» екенін түсінетін кезекші инженердің реакциясы арасында ақылға қонымды ымыраға келу керек шығар.
Перфекционизм мен нақты күш-жігер, уақыт пен ақша арасындағы ақылға қонымды ымыраға келу.
Бұл мәтін Александр Демидовтың конференцияда жасаған баяндамасының жаңартылған және кеңейтілген нұсқасы болып табылады .
Ақпарат көзі: www.habr.com