На сённяшні дзень у сэрвісу "Бітрыкс24" няма сотняў гігабіт трафіку, няма вялізнага парку сервераў (хоць і існуючых, вядома, нямала). Але для многіх кліентаў ён з'яўляецца асноўным інструментам працы ў кампаніі, гэта сапраўднае business-critical прыкладанне. Таму падаць - ну, ніяк нельга. А што калі падзенне ўсё ж такі здарылася, але «паўстаў» сэрвіс так хутка, што ніхто нічога і не заўважыў? І як атрымоўваецца рэалізаваць пры гэтым failover без страты якасці працы і колькасці кліентаў? Аляксандр Дзямідаў, дырэктар кірунку хмарных сэрвісаў «Бітрыкс24», распавёў для нашага блога аб тым, як за 7 гадоў існавання прадукта эвалюцыянавала сістэма рэзервавання.
«У выглядзе SaaS мы запусцілі „Бітрыкс24“ 7 гадоў таму. Галоўная складанасць, мусіць, была ў наступным: да запуску ў паблік у выглядзе SaaS гэты прадукт існаваў проста ў фармаце скрынкавага рашэння. Кліенты куплялі яго ў нас, размяшчалі ў сябе на серверах, заводзілі карпаратыўны партал - агульнае рашэнне для зносін супрацоўнікаў, захоўвання файлаў, вядзенне задач, CRM, вось гэта ўсё. І мы да 2012 года вырашылі, што хочам запусціць гэта як SaaS, адмініструючы самастойна, забяспечваючы адмоваўстойлівасць і надзейнасць. Досвед мы набіралі падчас, таму што датуль у нас яго проста не было — мы былі толькі вытворцамі ПА, не сэрвіс-правайдэрамі.
Запускаючы сэрвіс, мы разумелі, што самае галоўнае - гэта забяспечыць адмоваўстойлівасць, надзейнасць і пастаянную даступнасць сэрвісу, таму што калі ў вас просты звычайны сайт, крама, напрыклад, і ён упаў у вас і ляжыць гадзіна - пакутуеце толькі вы самі, вы губляеце заказы , Вы губляеце кліентаў, але для самога вашага кліента - для яго гэта не вельмі крытычна. Ён знерваваўся, вядома, але пайшоў і купіў на іншым сайце. А калі гэта дадатак, на якое завязана ўся праца ўнутры кампаніі, камунікацыі, рашэнні, то самае ключавое - гэта заваяваць давер карыстальнікаў, гэта значыць не падводзіць іх і не падаць. Таму што ўся праца можа ўстаць, калі нешта ўсярэдзіне працаваць не будзе.
Битрикс.24 як SaaS
Першы прататып мы сабралі за год да публічнага запуску, у 2011 годзе. Сабралі прыкладна за тыдзень, паглядзелі, пакруцілі - ён нават быў працуючы. Гэта значыць можна было зайсці ў форму, увесці там назву партала, разгортваўся новы партал, заводзілася база карыстальнікаў. Паглядзелі на яго, ацанілі ў прынцыпе прадукт, згарнулі, і цэлы год далей дапрацоўвалі. Таму што ў нас была вялікая задача: мы не хацелі рабіць дзве розныя кодавыя базы, мы не хацелі падтрымліваць асобна скрынкавы прадукт, асобна хмарныя рашэнні, — мы хацелі рабіць усё гэта ў рамках аднаго кода.
Тыповая вэб-прыкладанне на той момант - гэта адзін сервер, на якім круціцца нейкі код php, база mysql, файлы загружаюцца, дакументы, малюнкі кладуцца ў татачку upload - ну і ўсё гэта працуе. Нажаль, запускаць крытычна ўстойлівы вэб-сэрвіс на гэтым немагчыма. Тамака размеркаваны кэш не падтрымліваецца, рэплікацыя баз дадзеных не падтрымліваецца.
Мы сфармулявалі патрабаванні: гэтае ўменне размяшчацца ў розных лакейшнах, падтрымліваць рэплікацыю, у ідэале размяшчацца ў розных геаграфічна размеркаваных дата-цэнтрах. Падзяліць логіку прадукта і, уласна, захоўванне дадзеных. Дынамічна ўмець маштабавацца па нагрузцы, статыку ўвогуле вынесці. З гэтых меркаванняў склаліся, уласна, патрабаванні да прадукта, які мы як раз на працягу года і дапрацоўвалі. За гэты час у платформе, якая атрымалася адзінай - для скрыначных рашэнняў, для нашага ўласнага сэрвісу, - мы зрабілі падтрымку тых рэчаў, якія нам былі неабходныя. Падтрымку рэплікацыі mysql на ўзроўні самога прадукта: гэта значыць распрацоўнік, які піша код – не задумваецца, як яго запыты будуць размяркоўвацца, ён выкарыстоўвае наш api, а мы ўмеем правільна размяркоўваць запыты на запіс і на чытанне паміж майстрамі і слейвамі.
Мы зрабілі падтрымку на ўзроўні прадукта розных хмарных аб'ектных сховішчаў: google storage, amazon s3, - плюс, падтрымка open stack swift. Таму гэта было зручна і для нас як для сэрвісу, і для распрацоўшчыкаў, якія працуюць з скрынкавым рашэннем: калі яны выкарыстоўваюць проста наш api для працы, яны не задумваюцца, дзе ў выніку файл захаваецца, лакальна на файлавай сістэме або патрапіць у аб'ектнае файлавае сховішча. .
У выніку мы адразу вырашылі, што будзем рэзэрвавацца на ўзроўні цэлага дата-цэнтру. У 2012 годзе мы запускаліся цалкам у Amazon AWS, таму што ў нас ужо быў досвед працы з гэтай платформай – наш уласны сайт там размяшчаўся. Нас прыцягвала тое, што ў кожным рэгіёне ў Amazon'e ёсць некалькі зон даступнасці – у сутнасці, (у іх тэрміналогіі) некалькі дата-цэнтраў, якія больш-менш сябар ад сябра незалежныя і дазваляюць нам рэзервавацца на ўзроўні цэлага дата-цэнтра: калі ён раптам выходзіць са строю, базы рэпліцыруюцца master-master, серверы вэб-прыкладанняў зарэзерваваны, а статыка вынесена ў аб'ектнае сховішча s3. Нагрузка балансуецца - на той момант амазонаўскім elb, але крыху пазней мы прыйшлі да ўласных балансавальнікаў, таму што нам патрэбна была больш складаная логіка.
Што хацелі - тое і атрымалі ...
Усе базавыя рэчы, якія мы хацелі забяспечыць - адмоваўстойлівасць саміх сервераў, вэб-прыкладанняў, баз дадзеных - усё працавала добра. Самы просты сцэнар: калі ў нас выходзіць з ладу нейкае з вэб-прыкладанняў, то тут усё проста - яны выключаюцца з балансавання.
Якія выйшлі з ладу машыны балансавальнік (тады гэта быў амазонаўскі elb) сам пазначаў unhealthy, выключаў размеркаванне нагрузкі на іх. Працаваў амазонаўскі аўтаскейлінг: калі нагрузка вырастала, дадаваліся новыя машыны ў аўтаскейлінг-групу, нагрузка размяркоўвалася на новыя машыны - усё было добра. З нашымі балансавальнікамі логіка прыкладная тая ж самая: калі нешта здараецца з серверам прыкладанняў, мы прыбіраем з яго запыты, выкідаем гэтыя машыны, стартуем новыя і працягваем працаваць. Схема за ўсе гэтыя гады крыху змянялася, але працягвае працаваць: яна простая, зразумелая, і ніякіх цяжкасцяў з гэтым няма.
Мы працуем па ўсім свеце, пікі нагрузкі ў кліентаў абсалютна розныя, і, па-добраму, мы павінны мець магчымасць праводзіць тыя ці іншыя сэрвісныя работы з любымі кампанентамі нашай сістэмы ў любы час - незаўважна для кліентаў. Таму мы маем магчымасць выключыць з працы базу даных, пераразмеркаваўшы нагрузку на другі дата-цэнтр.
Як гэта ўсё працуе? - Трафік мы перамыкаем на працуючы дата-цэнтр - калі гэта аварыя на дата-цэнтры, то цалкам, калі гэта нашы планавыя працы з нейкай адной базай, то мы частка трафіку, які абслугоўвае гэтых кліентаў, перамыкаем на другі дата-цэнтр, прыпыняецца рэплікацыя. Калі патрэбныя новыя машыны для вэба-прыкладанняў, бо вырасла нагрузка на другім дата-цэнтры, яны аўтаматам стартуюць. Працы заканчваем, рэплікацыя аднаўляецца, і мы вяртаем усю нагрузку назад. Калі нам трэба люстрана правесці нейкія працы ў другім ДЦ, напрыклад, усталяваць сістэмныя абнаўленні ці змяніць налады ў другой базе дадзеных, то, увогуле, паўтараем усё тое ж самае, проста ў іншы бок. А калі гэта аварыя, то мы робім усё банальна: у сістэме маніторынгу выкарыстоўваем механізм event-handlers. Калі ў нас спрацоўвае некалькі праверак і статут пераходзіць у critical, то ў нас запускаецца гэты handler, апрацоўшчык, які можа выканаць тую ці іншую логіку. У нас для кожнай базы прапісана, які сервер з'яўляецца для яе failover'ам, і куды трэба пераключыць трафік у выпадку яе недаступнасці. Мы - так гістарычна склалася - выкарыстоўваем у тым ці іншым выглядзе nagios або якія-небудзь яго форкі. У прынцыпе, падобныя механізмы ёсць практычна ў любой сістэме маніторынгу, нешта больш складанае мы пакуль не выкарыстоўваем, але магчыма некалі будзем. Цяпер маніторынг спрацоўвае на недаступнасць і мае магчымасць нешта пераключыць.
Ці ўсе мы зарэзервавалі?
У нас шмат кліентаў з ЗША, шмат кліентаў з Еўропы, шмат кліентаў, якія бліжэй да Усходу - Японія, Сінгапур і гэтак далей. Зразумела, вялікая доля кліентаў у Расіі. Гэта значыць, праца далёка не ў адным рэгіёне. Карыстачам жадаецца хуткага водгуку, ёсць патрабаванні па выкананні розных лакальных законаў, і ўсярэдзіне кожнага рэгіёна мы рэзервуемся на два дата-цэнтра, плюс ёсць нейкія дадатковыя сэрвісы, якія, ізноў жа, зручна размяшчаць усярэдзіне аднаго рэгіёна — для кліентаў, якія ў гэтым рэгіёне працуюць. Апрацоўшчыкі REST, серверы аўтарызацыі, яны менш крытычныя для працы кліента ў цэлым, па іх можна перамыкацца з невялікай прымальнай затрымкай, але не жадаецца вынаходзіць ровары, як іх маніторыць і што з імі рабіць. Таму па максімуме мы спрабуем выкарыстоўваць ужо існуючыя рашэнні, а не развіваць у сябе нейкую кампетэнцыю па дадатковых прадуктах. І недзе мы банальна выкарыстоўваем пераключэнне на ўзроўні dns, прычым жвавасць сэрвісу вызначаем тым жа самым dns. У Amazon ёсць сэрвіс Route 53, але гэта не проста dns, у які можна запісы ўнесці і ўсё, - ён значна больш гнуткі і зручны. Праз яго можна пабудаваць гео-размеркаваныя сэрвісы з геолокациями, калі вы з яго дапамогай вызначаеце, адкуль прыйшоў кліент, і даяце яму тыя ці іншыя запісы - з яго дапамогай можна пабудаваць failover-архітэктуры. Тыя ж самыя health-checks наладжваюцца ў самім Route 53, вы задаяце endpoint, якія маніторыцца, задаяце метрыкі, задаяце, па якіх пратаколах вызначаць «жывасць» сэрвісу – tcp, http, https; задаяце перыядычнасць праверак, якія вызначаюць, сэрвіс жывы ці не. І ў самым dns прапісваеце, што будзе primary, што будзе secondary, куды перамыкацца, калі спрацоўвае health-check усярэдзіне route 53. Усё гэта можна зрабіць нейкімі іншымі прыладамі, але чым гэта зручна — адзін раз наладзілі і потым наогул не думаем пра тым, як у нас робяцца праверкі, як у нас ідзе пераключэнне: усё працуе само.
Першае "але": а як і чым рэзерваваць сам route 53? Ці мала, раптам з ім нешта здарыцца? Мы, на шчасце, ні разу на гэтыя граблі не наступалі, але зноў жа, наперадзе ў мяне будзе расказ, чаму мы задумваліся, што ўсё ж рэзерваваць трэба. Тут мы сцелем сабе саломку загадзя. Некалькі разоў у суткі мы робім поўную выгрузку ўсіх зон, якія ў нас у route 53 заведзены. API Amazon'a дазваляе іх спакойна аддаваць у JSON, і ў нас паднята некалькі рэзервовых сервераў, куды мы гэта канвертоўны, выгружаем у выглядзе канфігаў і маем, грубіянска кажучы, бэкапную канфігурацыю. У выпадку чаго мы можам хутка разгарнуць яе ўручную, не страцім дадзеныя налад dns.
Другое "але": што ў гэтай карціне яшчэ не зарэзервавана? Сам балансавальнік! У нас размеркаванне кліентаў па рэгіёнах зроблена вельмі проста. У нас ёсць дамены bitrix24.ru, bitrix24.com, .de – цяпер іх штук 13 розных, якія працуюць па самых розных зонах. Мы прыйшлі да наступнага: у кожным рэгіёне - свае балансавальнікі. Так зручней размяркоўваць па рэгіёнах, у залежнасці ад таго, якая дзе пікавая нагрузка па сетцы. Калі гэта збой на ўзроўні нейкага аднаго балансавальніка, то ён проста выводзіцца з эксплуатацыі і прыбіраецца з dns. Калі адбываецца нейкая праблема з групай балансавальнікаў, то яны рэзервуюцца на іншых пляцоўках, і пераключэнне паміж імі робіцца з дапамогай той жа самай route53, таму што за рахунак кароткага ttl пераключэнне адбываецца максімум на працягу 2, 3, 5 хвілін.
Трэцяе але: што яшчэ не зарэзервавана? S3, правільна. Мы, размяшчаючы файлы, якія захоўваем у карыстачоў у s3, – шчыра верылі, што ён бранябойны і нічога тамака рэзерваваць не трэба. Але гісторыя паказвае, што адбываецца інакш. Наогул, Amazon апісвае S3 як фундаментальны сэрвіс, таму што сам Amazon выкарыстоўвае S3 для захоўвання выяў машын, канфігаў, выяў AMI, снэпшотаў… І калі падае s3, як гэта аднойчы здарылася за гэтыя 7 гадоў, колькі мы bitrix24 эксплуатуем, ён за сабой веерам цягне кучу за ўсё - недаступнасць старту віртуалак, збой у працы api і гэтак далей.
І зваліцца S3 можа так здарылася аднойчы. Таму мы прыйшлі да наступнай схемы: яшчэ некалькі гадоў таму сур'ёзных аб'ектных публічных сховішчаў у Расіі не было, і мы разглядалі варыянт рабіць нешта сваё… На шчасце, мы гэтага рабіць не пачалі, бо закапаліся б у тую экспертызу, якой мы не валодаем, і напэўна накасячылі б. Цяпер s3-сумяшчальныя сховішчы ёсць у Mail.ru, ёсць у Яндэкса, ёсць яшчэ ў шэрагу правайдэраў. Мы ў выніку дашлі да думкі, што жадаем мець, па-першае, рэзерваванне, па-другое, магчымасць працы з лакальнымі копіямі. Для менавіта расійскага рэгіёну мы выкарыстоўваем сэрвіс Mail.ru Hotbox, які па api сумяшчальны з s3. Нам не запатрабавалася нейкіх сур'ёзных дапрацовак па кодзе ўсярэдзіне прыкладання, і мы зрабілі наступны механізм: у s3 ёсць трыгеры, якія спрацоўваюць на стварэнне/выдаленне аб'ектаў, у Amazon ёсць такі сэрвіс, як Лямбда - гэта serverless запуску кода, які выканаецца як раз пры спрацоўванні тых ці іншых трыгераў.
Мы зрабілі вельмі проста: калі ў нас спрацоўвае трыгер, мы выконваем код, які скапіюе аб'ект у сховішча Mail.ru. Каб паўнавартасна запусціць працу з лакальнымі копіямі дадзеных, нам патрэбная яшчэ зваротная сінхранізацыя, каб кліенты, якія знаходзяцца ў расійскім сегменце, маглі працаваць са сховішчам, якое да іх бліжэй. Mail вось-вось даробіць трыгеры ў сябе ў сховішча – можна будзе ўжо на ўзроўні інфраструктуры выконваць зваротную сінхранізацыю, пакуль жа мы гэта які робіцца на ўзроўні нашага ўласнага кода. Калі мы бачым, што кліент размясціў нейкі файл, то мы ў сябе на ўзроўні кода змяшчаем падзею ў чаргу, апрацоўваем яе і які робіцца зваротную рэплікацыю. Чым яна дрэнная: калі ў нас адбываецца нейкая праца з нашымі аб'ектамі па-за нашым прадуктам, гэта значыць нейкімі знешнімі сродкамі, мы гэта не ўлічым. Таму мы чакаем да канца, калі з'явяцца трыгеры на ўзроўні сховішча, каб незалежна ад таго, адкуль мы выканалі код, аб'ект, які да нас патрапіў, капіяваўся ў іншы бок.
На ўзроўні кода ў нас для кожнага кліента прапісваюцца абодва сховішчы: адно лічыцца асноўным, іншае бэкапным. Калі ўсё добра, мы працуем з тым сховішчам, якое да нас бліжэй: гэта значыць нашы кліенты, якія ў Amazon, яны працуюць з S3, а тыя, хто працуе ў Расіі, яны працуюць з Hotbox. Калі спрацоўвае сцяжок, то ў нас павінен далучыцца failover, і мы кліентаў перамыкаем на іншае сховішча. Мы гэты сцяжок можам ставіць незалежна па рэгіёнах і можам іх туды-сюды пераключаць. На практыцы яшчэ гэтым не карысталіся, але механізм гэты прадугледзелі і думаем, што калісьці нам гэтае самае пераключэнне спатрэбіцца і спатрэбіцца. Аднаго разу гэта ўжо здарылася.
Ой, а ў вас Amazon збег…
У гэтым красавіку – гадавіна пачатку блакіровак Тэлеграм у Расіі. Самы пацярпелы правайдэр, які пад гэта патрапіў, – Amazon. І, нажаль, больш пацярпелі расійскія кампаніі, якія працавалі на ўвесь мір.
Калі кампанія глабальная і Расія для яе - зусім маленькі сегмент, 3-5% - ну, так ці інакш, можна імі ахвяраваць.
Калі гэта асабліва расійская кампанія - я ўпэўнены, што трэба размяшчацца лакальна - ну проста самім карыстальнікам будзе зручна, камфортна, рызык будзе менш.
А калі гэта кампанія, якая працуе глабальна, і ў яе прыкладна пароўну кліентаў з Расіі, і недзе па свеце? Сувязь сегментаў важная, і працаваць сябар з сябрам яны так ці інакш павінны.
Яшчэ ў канцы сакавіка 2018-га Роскомнадзор накіраваў самым вялікім аператарам ліст, аб тым, што яны плануюць заблакаваць некалькі мільёнаў ip Amazon, для таго каб заблакаваць ... мэсанджар Zello. Дзякуй гэтым самым правайдэрам – яны ліст паспяхова ўсім злілі, і ўзнікла разуменне, што складнасць c Amazon можа разваліцца. Гэта была пятніца, мы ў паніцы прыбеглі да калег з servers.ru, са словамі: "Сябры, нам трэба некалькі сервераў, якія будуць стаяць не ў Расіі, не ў Amazon, а, напрыклад, дзе-небудзь у Амстэрдаме", для таго каб мець магчымасць хаця б якім-небудзь чынам паставіць там уласныя vpn і proxy для нейкіх endpoint'аў, на якія мы ніяк не можам уплываць, напрыклад endpont'ы таго ж s3 - нельга паспрабаваць падняць новы сэрвіс і атрымаць іншы ip, нам усё роўна трэба туды дастукацца. За некалькі дзён мы гэтыя серверы наладзілі, паднялі, і ўвогуле, да моманту пачатку блакіровак падрыхтаваліся. Цікаўна, што РКН, паглядзеўшы на шуміху і паднятую паніку, сказаў: "Не, мы зараз блакаваць нічога не будзем". (Але гэта роўна да таго моманту, калі пачалі блакаваць тэлеграм.) Наладзіўшы магчымасці абыходу і зразумеўшы, што блакіроўку не ўвялі, мы, тым не менш, не сталі ўсю гэтую справу разбіраць. Так, на ўсялякі выпадак.
І вось у 2019 годзе мы жывем ва ўмовах блакіровак. Я вось учора ўначы глядзеў: каля мільёна ip працягваюць блакавацца. Праўда, Amazon амаль у поўным складзе разблакавалі, у піку даходзіла да 20 мільёнаў адрасоў… Увогуле, рэальнасць такая, што складнасці, добрай складнасці – яе можа не быць. Раптам. Яе можа не быць па тэхнічных прычынах - пажары, экскаватары, усё такое. Або, як мы бачылі, не зусім тэхнічным. Таму хтосьці вялікі і буйны, з уласнымі AS-камі, мусіць, можа гэтым руліць іншымі шляхамі, direct connect і іншыя рэчы ўжо на ўзроўні l2. Але ў простым варыянце, як мы ці яшчэ мяльчэй, можна на ўсялякі выпадак мець рэзерваванне на ўзроўні сервераў, паднятых дзесьці яшчэ, настроеных загадзя vpn, proxy, з магчымасцю хутка на іх перамыкаць канфігурацыю ў тых сегментах, якія ў вас крытычныя па складнасці . Гэта нам спатрэбілася неаднаразова, калі пачаліся блакіроўкі Amazon, мы праз іх пускалі ў самым горшым выпадку як раз трафік S3, але паступова ўсё гэта разрулілася.
А як рэзерваваць… цэлага правайдэра?
Цяпер сцэнара на выпадак выхаду са строю ўсяго Amazon у нас няма. У нас падобны сцэнар ёсць для Расіі. Мы ў Расіі размяшчаліся ў аднаго правайдэра, у якога мы выбіралі, каб было некалькі пляцовак. І год таму мы сутыкнуліся з праблемай: нават нягледзячы на тое, што гэта два дата-цэнтры, ужо на ўзроўні канфігурацыі сеткі правайдэра могуць быць праблемы, якія закрануць усё роўна абодва даты-цэнтры. І мы можам атрымаць недаступнасць на абедзвюх пляцоўках. Канечне, так і здарылася. Мы ў выніку перагледзелі архітэктуру ўсярэдзіне. Яна не вельмі моцна змянілася, але для Расіі ў нас зараз дзве пляцоўкі, якія не ў аднаго правайдэра, а ў дзвюх розных. Калі ў аднаго нешта выйдзе са строю, мы можам пераключыцца на іншага.
Гіпатэтычна мы для Amazon разглядаем магчымасць рэзерваваць на ўзроўні іншага правайдэра; можа быць, Google, можа быць, яшчэ хтосьці… Але пакуль мы назіралі на практыцы, што калі ў Amazon аварыі на ўзроўні адной availability-зоны здараюцца, то аварыі на ўзроўні цэлага рэгіёна - дастаткова рэдкая з'ява. Таму мы тэарэтычна маем уяўленне аб тым, што мы, можа быць, зробім рэзерваванне "Amazon – не Amazon", але на практыцы такога пакуль няма.
Пары слоў пра аўтаматызацыю
Ці заўсёды патрэбна аўтаматыка? Тут дарэчы ўспомніць эфект Данінга-Кругера. Па восі "х" нашы веды і досвед, якога мы набіраемся, а па восі "у" - упэўненасць у нашых дзеяннях. Мы спачатку не ведаем нічога і зусім не ўпэўненыя. Затым мы ведаем трошкі і становімся мега-ўпэўненымі - гэта так званы "пік дурасці", добра ілюструецца карцінкай "прыдуркаватасць і адвага". Далей мы ўжо крыху навучыліся і гатовы ісці ў бой. Потым мы наступаем на нейкія мега-сур'ёзныя граблі, трапляем у даліну роспачы, калі быццам нешта ведаем, а насамрэч мы шмат чаго не ведаем. Затым, па меры набору досведу, становімся ўжо больш упэўненымі.
Наша логіка пра розныя пераключэнні аўтаматычна на тыя ці іншыя аварыі - яна вельмі добра апісваецца гэтым графікам. Мы стартавалі - мы нічога не ўмелі, практычна ўсе працы праводзіліся ўручную. Потым мы зразумелі, што можна на ўсё навесіць аўтаматыку і, тыпу, спаць спакойна. І раптам мы надыходзім на мега-граблі: у нас спрацоўвае false positive, і мы перамыкаем туды-сюды трафік, калі, па-добраму, не варта было гэтага рабіць. Такім чынам, ламаецца рэплікацыя ці яшчэ што-небудзь - вось тая самая даліна роспачы. А далей прыходзім да разумення, што да ўсяго трэба ставіцца з розумам. Гэта значыць мае сэнс пакласціся на аўтаматыку, прадугледзеўшы магчымасць фальшывага спрацоўвання. Але! калі наступствы могуць быць разбуральнымі, то лепш аддаць гэта на водкуп дзяжурнай змене, дзяжурным інжынерам, якія пераканаюцца, прасочаць, што сапраўды аварыя, і неабходныя дзеянні выканаюць уручную…
Заключэнне
За 7 гадоў мы прайшлі шлях ад таго, што, калі нешта падала, - была паніка-паніка, да разумення, што праблем не існуе, ёсць толькі задачы, іх неабходна - і можна - вырашаць. Калі вы будуеце нейкі сэрвіс, паглядзіце на яго поглядам зверху, ацаніце ўсе рыскі, якія могуць здарыцца. Калі вы адразу бачыце іх - то загадзя прадугледжвайце рэзерваванне і магчымасць пабудовы адмоваўстойлівай інфраструктуры, таму што любая кропка, якая можа выйсці з ладу і прывесці да непрацаздольнасці сэрвісу - яна абавязкова гэта зробіць. І нават калі вам здаецца, што нейкія элементы інфраструктуры сапраўды не выйдуць з ладу - тыпу таго ж s3, усё роўна майце на ўвазе, што яны могуць. І хаця б у тэорыі майце ўяўленне аб тым, што вы будзеце з імі рабіць, калі нешта ўсё ж такі здарыцца. Майце план па адпрацоўцы рызык. Калі вы задумваецеся аб тым, каб рабіць усё аўтаматыкай ці ўручную, - ацаніце рызыкі: што будзе, калі аўтаматыка пачне ўсё перамыкаць - ці не прывядзе гэта да яшчэ горшай карціны ў параўнанні з аварыяй? Магчыма, дзесьці трэба выкарыстоўваць разумны кампраміс паміж выкарыстаннем аўтаматыкі і рэакцыяй дзяжурнага інжынера, які ацэніць рэальную карціну і зразумее, ці трэба з ходу нешта пераключыць ці "так, але не зараз".
Разумны кампраміс паміж перфекцыянізм і рэальнымі сіламі, часам, грашыма, якія вы можаце выдаткаваць на тую схему, якая ў вас у выніку будзе.
Гэты тэкст з'яўляецца дапоўненай і пашыранай версіяй даклада Аляксандра Дзямідава на канферэнцыі .
Крыніца: habr.com