Бүгүнкү күндө Bitrix24 кызматында жүздөгөн гигабит трафик жок жана серверлердин чоң паркы жок (бирок, албетте, бир нече бар). Бирок көптөгөн кардарлар үчүн бул компанияда иштөө үчүн негизги курал болуп саналат, бул реалдуу бизнес-критикалык колдонмо болуп саналат; Ошондуктан жыгылып калууга жол жок. Эгер кыйроо болуп, бирок кызмат ушунчалык тез "калыбына келтирилсе", эч ким эч нерсени байкабай калсачы? Ал эми иштин сапатын жана кардарлардын санын жоготпостон, жаңылоону кантип ишке ашырууга болот? Bitrix24 булут кызматтарынын директору Александр Демидов биздин блог үчүн продукттун 7 жыл ичинде ээлөө системасы кандайча өнүгүп кеткени жөнүндө айтып берди.
«Биз Bitrix24тү 7 жыл мурун SaaS катары ишке киргиздик. Негизги кыйынчылык, кыязы, төмөнкүдөй болгон: ал SaaS катары ачыкка чыкканга чейин, бул продукт жөн гана кутулуу чечим форматында болгон. Кардарлар аны бизден сатып алып, өз серверлеринде жайгаштырышты, корпоративдик порталды түзүштү - кызматкерлердин баарлашуусу, файлдарды сактоо, тапшырмаларды башкаруу, CRM үчүн жалпы чечим, бардыгы. Ал эми 2012-жылга чейин биз аны SaaS катары ишке киргизели деп чечтик, аны өзүбүз башкарып, каталарга чыдамдуулукту жана ишенимдүүлүктү камсыз кылабыз. Биз бул жолдо тажрыйбага ээ болдук, анткени ага чейин бизде андай болгон эмес – биз кызмат көрсөтүүчү эмес, программалык камсыздоону өндүрүүчүлөр болчубуз.
Кызматты ишке киргизүүдө биз эң негизгиси катачылыкка чыдамдуулукту, кызматтын ишенимдүүлүгүн жана туруктуу жеткиликтүүлүгүн камсыз кылуу экенин түшүндүк, анткени, мисалы, сизде жөнөкөй жөнөкөй веб-сайтыңыз, дүкөнүңүз болсо, ал сизге түшүп, ошол жерде отурат. бир саат, сиз гана кыйналасыз, сиз заказдарды жоготосуз, кардарларды жоготосуз, бирок сиздин кардарыңыз үчүн бул ал үчүн өтө маанилүү эмес. Албетте капа болду, бирок башка сайттан барып сатып алды. Ал эми бул компаниянын ичиндеги бардык иштер, коммуникациялар, чечимдер байланган тиркеме болсо, анда эң негизгиси колдонуучулардын ишенимине ээ болуу, башкача айтканда, аларды түшүрбөө жана кулап калбоо. Анткени ичиндеги бир нерсе иштебесе бардык иш токтоп калышы мүмкүн.
Bitrix.24 SaaS катары
Биз биринчи прототибин коомчулукка чыгаруудан бир жыл мурун, 2011-жылы чогултканбыз. Биз аны бир жуманын ичинде чогулттук, карап чыктык, бурап койдук - ал тургай иштеп жаткан. Башкача айтканда, формага кирип, ошол жерге порталдын атын киргизсеңиз болот, жаңы портал ачылып, колдонуучу база түзүлмөк. Биз карап чыктык, продукцияны принципиалдуу түрдө бааладык, аны жарактан чыгардык жана бир жыл бою тактоо иштерин уланттык. Анткени биздин алдыбызда чоң тапшырма бар болчу: биз эки башка код базасын түзгүбүз келген жок, биз өзүнчө пакеттелген продуктуну, өзүнчө булут чечимдерин колдогубуз келген жок - мунун баарын бир коддун ичинде жасагыбыз келди.
Ошол кездеги типтүү веб-тиркеме PHP коду иштеген бир сервер болгон, MySQL маалымат базасы, файлдар жүктөлгөн, документтер, сүрөттөр жүктөө папкасына салынган - баары иштейт. Тилекке каршы, муну колдонуу менен критикалык туруктуу желе кызматын ишке киргизүү мүмкүн эмес. Ал жерде бөлүштүрүлгөн кэш колдоого алынбайт, маалымат базасын репликациялоо колдоого алынбайт.
Биз талаптарды түздүк: бул ар кандай жерлерде жайгашуу, репликацияны колдоо жана идеалдуу түрдө ар кандай географиялык бөлүштүрүлгөн маалымат борборлорунда жайгашуу мүмкүнчүлүгү. Продукт логикасын жана чындыгында маалыматтарды сактоону бөлүңүз. Жүктөлүшкө жараша динамикалык масштабда жана статикага толугу менен чыдай билүү. Бул ой-пикирлерден, чындыгында, биз жыл бою такталган продукцияга талаптар пайда болду. Бул убакыттын ичинде, бирдиктүү болуп чыккан платформада - кутулуу чечимдер үчүн, өзүбүздүн кызматыбыз үчүн - биз керектүү нерселерди колдодук. Продукттун өз деңгээлинде MySQL репликациясын колдоо: башкача айтканда, кодду жазган иштеп чыгуучу анын суроо-талаптары кандай бөлүштүрүлөт деп ойлобойт, ал биздин api колдонот жана биз мастерлердин ортосунда жазуу жана окуу сурамдарын туура бөлүштүрүүнү билебиз. жана кулдар.
Биз продукт деңгээлинде ар кандай булут объекттеринин сактагычтары үчүн колдоо көрсөттүк: google сактагычы, amazon s3, плюс ачык стек Swift үчүн колдоо. Ошондуктан, бул кызмат катары биз үчүн да, пакеттелген чечим менен иштеген иштеп чыгуучулар үчүн да ыңгайлуу болду: эгер алар биздин APIди жумуш үчүн гана колдонушса, алар файлдын кайсы жерде сакталаарын ойлошпойт, файл тутумунда же локалдык түрдө. объект файл сактагычында.
Натыйжада, биз дароо эле бүт маалымат борборунун деңгээлинде резервге алууну чечтик. 2012-жылы биз толугу менен Amazon AWS'те ишке кирдик, анткени бул платформада тажрыйбабыз бар болчу - биздин веб-сайтыбыз ошол жерде жайгаштырылган. Ар бир аймакта Amazon бир нече жеткиликтүү зоналары бар экендиги бизди кызыктырды - чындыгында, (алардын терминологиясында) бири-биринен аздыр-көптүр көз каранды эмес жана бүтүндөй бир маалымат борборунун деңгээлинде резервдештирүү мүмкүнчүлүгүн берген бир нече маалымат борборлору: эгер ал күтүлбөгөн жерден иштебей калса, маалымат базалары мастер-мастер репликацияланат, веб-тиркеме серверлеринин резервдик көчүрмөсү сакталат жана статикалык маалыматтар s3 объект сактагычына жылдырылат. Жүк тең салмактуу - ошол кезде Amazon elb тарабынан, бирок бир аздан кийин биз өзүбүздүн жүк балансчыларга келдик, анткени бизге татаалыраак логика керек болчу.
Алар каалаган нерсеге ээ болду ...
Биз камсыз кылгыбыз келген бардык негизги нерселер - серверлердин өздөрүнүн каталарына чыдамдуулук, веб-тиркемелер, маалымат базалары - баары жакшы иштеди. Эң жөнөкөй сценарий: эгер биздин веб-тиркемелерибиздин бири иштебей калса, анда бардыгы жөнөкөй - алар тең салмактуулуктан өчүрүлөт.
Балансатор (ал кезде Амазондун тиштери болчу) иштен чыккан машиналарды ден-соолукка зыян деп белгилеп, аларга жүк бөлүштүрүүнү өчүргөн. Amazon autoscaling иштеди: жүк чоңойгондо, автоскалдоо тобуна жаңы машиналар кошулду, жүк жаңы машиналарга бөлүштүрүлдү - баары жакшы болду. Биздин баланстоочулар менен логика болжол менен бирдей: эгер тиркеме серверине бир нерсе болуп кетсе, биз андан сурамдарды алып салабыз, бул машиналарды ыргытып, жаңыларын баштайбыз жана иштөөнү улантабыз. Схема жылдар бою бир аз өзгөрдү, бирок ишин улантууда: бул жөнөкөй, түшүнүктүү жана аны менен эч кандай кыйынчылыктар жок.
Биз бүткүл дүйнө жүзү боюнча иштейбиз, кардарлардын жүктөмүнүн эң жогорку чеги такыр башкача, жана ынтымактуу түрдө, кардарларга байкалбастан, каалаган убакта системабыздын бардык компоненттеринде белгилүү бир тейлөө иштерин жүргүзө алышыбыз керек. Ошондуктан, бизде экинчи маалымат борборуна жүктөмдү кайра бөлүштүрүү менен, маалымат базасын иштен өчүрүү мүмкүнчүлүгү бар.
Мунун баары кантип иштейт? — Биз трафикти иштеп жаткан дата борборуна которабыз - эгер дата борборунда авария болуп калса, анда толугу менен, эгерде бул биздин бир маалымат базасы менен пландаштырылган ишибиз болсо, анда биз бул кардарларды тейлеген трафиктин бир бөлүгүн экинчи дата борборуна которуп, убактылуу токтотобуз. анын репликациясы. Эгерде экинчи маалымат борборуна жүктөм көбөйүп кеткендиктен веб-тиркемелер үчүн жаңы машиналар керек болсо, алар автоматтык түрдө иштей баштайт. Биз ишти бүтүрөбүз, репликация калыбына келтирилет жана биз бүт жүктү кайра кайтарабыз. Экинчи ДКда кандайдыр бир ишти чагылдырышыбыз керек болсо, мисалы, системанын жаңыртууларын орнотуу же экинчи маалымат базасында орнотууларды өзгөртүү, анда жалпысынан, биз ошол эле нерсени башка багытта кайталайбыз. Ал эми бул кокустук болсо, анда биз бардыгын майда-чүйдөсүнө чейин жасайбыз: мониторинг системасында окуяны башкаруучу механизмди колдонобуз. Эгерде бир нече текшерүүлөр жүргүзүлүп, абал критикалык абалга келсе, анда биз бул иштеткичти, тигил же бул логиканы аткара ала турган иштеткичти иштетебиз. Ар бир маалымат базасы үчүн биз анын кайсы серверин алмаштыруучу сервер экенин жана ал жеткиликсиз болсо, трафикти кайсы жерде алмаштыруу керектигин белгилейбиз. Тарыхый жактан биз нагиосту же анын айрым айрыларын тигил же бул формада колдонобуз. Принцибинде, ушуга окшош механизмдер дээрлик бардык мониторинг системасында бар. Азыр мониторинг жеткиликсиздиктен келип чыгат жана бир нерсени которуу мүмкүнчүлүгүнө ээ.
Биз бардыгын сактадыкпы?
Бизде АКШдан көптөгөн кардарлар бар, Европадан көп кардарлар бар, Чыгышка жакыныраак - Япония, Сингапур жана башкалар. Албетте, кардарлардын чоң үлүшү Орусияда. Башкача айтканда, иш бир эле аймакта эмес. Колдонуучулар тез жооп берүүнү каалашат, ар кандай жергиликтүү мыйзамдарды сактоо талаптары бар жана ар бир аймакта биз экиден маалымат борборун сактайбыз, ошондой эле бир нече кошумча кызматтар бар, аларды дагы бир аймактын ичинде жайгаштырууга ыңгайлуу - бул жерде турган кардарлар үчүн бул аймак иштеп жатат. REST иштеткичтери, авторизация серверлери, алар бүтүндөй кардардын иштеши үчүн анча маанилүү эмес, алар аркылуу бир аз алгылыктуу кечигүү менен которула аласыз, бирок сиз аларды кантип көзөмөлдөө жана эмне кылуу керектиги боюнча дөңгөлөктү кайра ойлоп тапкыңыз келбейт. алар менен. Ошондуктан, биз кошумча өнүмдөрдүн кандайдыр бир компетенттүүлүгүн өнүктүрүүгө караганда, болгон чечимдерди максималдуу колдонууга аракет кылып жатабыз. Жана кайсы бир жерде биз DNS деңгээлинде которуштурууну майда-чүйдөсүнө чейин колдонобуз жана ошол эле DNS аркылуу кызматтын жандуулугун аныктайбыз. Амазонкада 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 сүрөттөрүн, көз ирмемдик сүрөттөрүн сактоо үчүн колдонот... Жана эгер s3 бузулуп калса, бул 7 жыл ичинде бир жолу болуп өткөндөй, биз колдонуп келгенче bitrix24, ал аны күйөрман сыяктуу ээрчийт. Көптөгөн нерселер пайда болот - виртуалдык машиналарды ишке киргизүү мүмкүн эместиги, api иштебей калышы жана башкалар.
Ал эми S3 кулап калышы мүмкүн - бул бир жолу болгон. Ошондуктан, биз төмөнкү схемага келдик: бир нече жыл мурун Россияда олуттуу коомдук объектилерди сактоочу жайлар жок болчу, биз өзүбүздүн эле бир нерсе кылууну чечкенбиз... Бактыга жараша, биз муну баштаган жокпуз, анткени Бизде жок тажрыйбаны казып алганбыз, балким, баш аламандык кылат. Азыр Mail.ru s3-шайкеш сактагычка ээ, Яндекс ал бар жана башка бир катар провайдерлерде бар. Акыры, биз биринчиден, резервдик көчүрмөгө ээ болгубуз келет, экинчиден, жергиликтүү көчүрмөлөр менен иштөө мүмкүнчүлүгүнө ээ болгубуз келет деген ойго келдик. Орус аймагы үчүн биз Mail.ru Hotbox кызматын колдонобуз, ал API s3 менен шайкеш келет. Бизге тиркеменин ичиндеги кодго эч кандай олуттуу өзгөртүүлөрдү киргизүүнүн кереги жок болчу жана биз төмөнкү механизмди жасадык: s3-те объекттерди түзүүгө/жок кылууга түрткү берүүчү триггерлер бар, Amazonда Lambda деген сервис бар - бул коддун серверсиз ишке киргизилиши. бул белгилүү бир триггерлер иштетилгенде гана аткарылат.
Биз муну абдан жөнөкөй кылдык: эгерде биздин триггер күйүп кетсе, биз объектти Mail.ru сактагычына көчүрө турган кодду аткарабыз. Берилиштердин жергиликтүү көчүрмөлөрү менен ишти толук баштоо үчүн, орус сегментинде турган кардарлар аларга жакыныраак сактагыч менен иштей алышы үчүн, бизге тескери синхрондоштуруу керек. Почта өзүнүн сактагычындагы триггерлерди аяктоо алдында турат - инфраструктура деңгээлинде тескери синхрондоштурууну ишке ашырууга мүмкүн болот, бирок азыр биз муну өзүбүздүн кодубуздун деңгээлинде аткарып жатабыз. Эгерде биз кардар файлды жайгаштырганын көрсөк, анда код деңгээлинде окуяны кезекке коюп, аны иштетип, тескери репликация жасайбыз. Эмне үчүн бул жаман: эгерде биз буюмдарыбыз менен кандайдыр бир ишти биздин продукттан тышкары, башкача айтканда, кандайдыр бир тышкы каражаттар менен аткарсак, биз аны эске албайбыз. Ошондуктан, биз аягына чейин күтөбүз, триггерлер сактоо деңгээлинде пайда болгондо, кодду кайсы жерден аткарбайлы, бизге келген объект башка багытта көчүрүлөт.
Код деңгээлинде биз ар бир кардар үчүн эки сактагычты тең каттайбыз: бири негизги, экинчиси резервдик деп эсептелет. Эгер баары жакшы болсо, биз өзүбүзгө жакыныраак сактагыч менен иштейбиз: башкача айтканда, Amazon'да болгон кардарларыбыз S3 менен иштешет, ал эми Россияда иштегендер Hotbox менен иштешет. Эгер желек иштетилсе, анда жаңылыштык туташуу керек жана биз кардарларды башка сактагычка котордук. Биз бул кутучаны аймактар боюнча өз алдынча белгилей алабыз жана аларды алдыга жана артка которсок болот. Биз муну азырынча иш жүзүндө колдоно элекпиз, бирок биз бул механизмди камсыздаганбыз жана качандыр бир күнү бизге дал ушул которгуч керек болуп калат жана пайдалуу болот деп ойлойбуз. Бул буга чейин бир жолу болгон.
Ох, жана Amazon качып кетти ...
Ушул жылдын апрель айында Орусияда Telegram бөгөттөө башталганынын бир жылдыгы белгиленет. Эң көп жабыр тарткан провайдер Amazon болуп саналат. Анан, тилекке каршы, бүткүл дүйнө үчүн иштеген орусиялык компаниялар көбүрөөк жабыр тартышты.
компания глобалдуу болсо жана Россия ал үчүн абдан кичинекей сегменти болуп саналат, 3-5% - жакшы, тигил же бул жол менен, сиз аларды курмандыкка чалууга болот.
Эгер бул таза орусиялык компания болсо - мен аны жергиликтүү жерде жайгаштыруу керек деп ишенем - бул жөн гана колдонуучулардын өздөрү үчүн ыңгайлуу, ыңгайлуу жана тобокелдиктер азыраак болот.
Бул дүйнө жүзү боюнча иштеген жана Россиядан жана дүйнөнүн кайсы бир бурчунан келген кардарларынын болжолдуу санына ээ компания болсочу? Сегменттердин байланышы маанилүү жана алар бири-бири менен тигил же бул жол менен иштеши керек.
2018-жылдын март айынын аягында Роскомнадзор ири операторлорго кат жөнөтүп, алар Zello мессенджерине бөгөт коюу үчүн бир нече миллион Amazon IP даректерин бөгөттөп салууну пландап жатышканын билдирген. Ушул эле провайдерлерге рахмат - алар катты бардыгына ийгиликтүү ачып беришти жана Amazon менен байланыш үзүлүп кетиши мүмкүн деген түшүнүк бар. Бул жума күнү эле, биз серверs.ru сайтындагы кесиптештерибизге: "Достор, бизге Россияда эмес, Амазонкада эмес, мисалы, Амстердамдын бир жеринде жайгашкан бир нече серверлер керек" деген сөздөр менен чуркадык. жок дегенде кандайдыр бир жол менен биз эч кандай таасир эте албаган кээ бир акыркы чекиттер үчүн өзүбүздүн VPN жана проксиди орното алуу үчүн, мисалы, ошол эле s3тин endponts - биз жаңы кызматты көтөрүүгө жана башкасын алууга аракет кыла албайбыз. ip, биз сиз дагы ал жакка жетишиңиз керек. Бир нече күндүн ичинде биз бул серверлерди орнотуп, аларды ишке киргиздик жана жалпысынан бөгөттөө башталган учурга даярдандык. РКН ызы-чуу жана дүрбөлөңгө карап: "Жок, биз азыр эч нерсеге бөгөт койбойбуз" деп айтканы кызык. (Бирок бул дал Telegram бөгөттөле баштаган учурга чейин.) Айланып өтүү мүмкүнчүлүктөрүн орнотуп, бөгөттөө киргизиле электигин түшүнгөнүбүз менен, биз маселенин баарын чечип баштаган жокпуз. Ооба, кандайдыр бир учурда.
Ал эми азыр 2019-жылы биз дагы эле бөгөттөө шарттарында жашап жатабыз. Мен кечээ кечинде карадым: миллионго жакын IP бөгөттөлүүдө. Ырас, Амазонка дээрлик толугу менен бөгөттөн чыгарылды, анын туу чокусунда 20 миллион дарекке жетти... Жалпысынан алганда, ырааттуулук, жакшы ырааттуулук болбошу мүмкүн. күтүлбөгөн жерден. Бул техникалык себептерден улам жок болушу мүмкүн - өрт, экскаватор, бардык. Же, биз көргөндөй, толугу менен техникалык эмес. Ошондуктан, чоң жана чоң бирөө, өзүнүн АСлары бар, муну башка жолдор менен башкара алат - түз байланыш жана башка нерселер l2 деңгээлинде. Бирок жөнөкөй версияда, биздикиндей же андан да кичине, сиз, башка жерде көтөрүлгөн, алдын ала VPN, прокси конфигурацияланган серверлердин деңгээлинде резервдикке ээ боло аласыз, конфигурацияны ошол сегменттерде аларга тез которуу мүмкүнчүлүгү бар. алар сиздин байланышыңыз үчүн маанилүү. Бул бизге бир эмес, бир нече жолу пайдалуу болду, эң начар сценарийде, биз алар аркылуу S3 трафигине уруксат бердик, бирок мунун баары акырындык менен чечилди.
Бүтүндөй провайдерди кантип ээлөө керек?
Азыр бизде бүтүндөй Амазонка кыйраса сценарий жок. Бизде Орусия үчүн да ушундай сценарий бар. Россияда бизди бир провайдер тейледи, анын ичинен биз бир нече сайттарды тандап алдык. Жана бир жыл мурун биз көйгөйгө туш болдук: бул эки маалымат борбору болсо да, провайдердин тармак конфигурациясынын деңгээлинде көйгөйлөр болушу мүмкүн, алар дагы деле эки маалымат борборлоруна тең таасир этет. Жана биз эки сайтта тең жеткиликсиз болуп калышыбыз мүмкүн. Албетте, ошондой болгон. Ичиндеги архитектураны кайра карап бүттүк. Бул анча деле өзгөргөн жок, бирок Орусия үчүн азыр бизде эки сайт бар, алар бир эле провайдерден эмес, эки башка сайттан. Бирөөсү иштебей калса, экинчисине өтө алабыз.
Гипотетикалык түрдө, Amazon үчүн биз башка провайдердин деңгээлинде ээлөө мүмкүнчүлүгүн карап жатабыз; балким, Google, балким, башка бирөө... Бирок ушул убакка чейин биз практикада байкадык, Amazon бир жеткиликтүүлүк зонанын деңгээлинде кырсыкка учураса, бүтүндөй бир аймактын деңгээлинде кырсыктар өтө сейрек кездешет. Ошондуктан, биз теориялык жактан "Amazon бул Amazon эмес" резервин түзө алабыз деген ойдобуз, бирок иш жүзүндө андай эмес.
Автоматташтыруу жөнүндө бир нече сөз
Автоматташтыруу ар дайым керекпи? Бул жерде Даннинг-Крюгер эффектин эске салуу орундуу. "X" огунда биз алган билимибиз жана тажрыйбабыз, ал эми "y" огунда иш-аракеттерибизге болгон ишеним. Башында биз эч нерсе билбейбиз жана такыр ишенбейбиз. Ошондо биз бир аз билип, өзүнө ишенип калабыз - бул "акылсыздыктын туу чокусу" деп аталган "акылсыздык жана кайраттуулук" сүрөтү менен жакшы сүрөттөлгөн. Ошондо биз бир аз үйрөнүп, согушка чыгууга даярбыз. Анан биз бир нерсени билип жаткандай сезилгенде, бирок чындыгында биз көп нерсени билбегенибизде, кээ бир олуттуу каталарды басып, үмүтсүздүк өрөөнүндө болобуз. Анан тажрыйба топтогон сайын өзүбүзгө дагы ишенебиз.
Кээ бир кырсыктарга ар кандай автоматтык которуулар жөнүндөгү биздин логика бул графикте абдан жакшы сүрөттөлгөн. Биз баштадык - биз эч нерсе кылганды билбей калдык, дээрлик бардык жумуш кол менен жасалды. Ошондо биз бардык нерсеге автоматташтырууну кошуп, тынч уктай аларыбызды түшүндүк. Жана күтүлбөгөн жерден биз мега-рейкке кадам таштайбыз: жалган позитив пайда болот жана биз трафикти алдыга-артка алмаштырып жатабыз, качан жакшы жол менен муну кылбашыбыз керек болчу. Демек, репликация бузулат же башка нерсе – бул үмүтсүздүк өрөөнү. Анан бардык нерсеге акылмандык менен мамиле кылуу керек деген түшүнүккө келебиз. Башкача айтканда, жалган сигналдарды берүү мүмкүнчүлүгүн камсыз кылуу менен автоматташтырууга таянуу акылга сыярлык. Бирок! кесепеттери кыйраткыч болушу мүмкүн болсо, анда аны нөөмөт нөөмөтүнө, нөөмөттөгү инженерлерге тапшырган жакшы, алар чындап эле авария болуп жатканын текшерип, көзөмөлдөп, керектүү иш-аракеттерди кол менен жүргүзүшөт...
жыйынтыктоо
7 жылдын ичинде биз бир нерсе кулаганда дүрбөлөңгө түшкөндөн, көйгөйлөр жок, милдеттер гана бар, аларды чечүү керек жана чечилиши мүмкүн деген түшүнүккө өттүк. Кызматты куруп жатканыңызда, аны жогору жактан караңыз, болушу мүмкүн болгон бардык тобокелдиктерди баалаңыз. Эгерде сиз аларды дароо көрүп турсаңыз, анда алдын ала ашыкчаларды жана каталарга чыдамдуу инфраструктураны куруу мүмкүнчүлүгүн камсыз кылыңыз, анткени иштебей калышы мүмкүн жана кызматтын иштебей калышына алып келе турган бардык пункттар сөзсүз түрдө ушундай кылат. Жана сизге кээ бир инфраструктуралык элементтер сөзсүз түрдө иштебей тургандай сезилсе дагы, мисалы, s3, алар мүмкүн экенин унутпаңыз. Жок дегенде, теориялык жактан алганда, бир нерсе болуп калса, алар менен эмне кыла турганыңызды түшүнүңүз. Тобокелдиктерди башкаруу планы бар. Баарын автоматтык түрдө же кол менен жасоону ойлонуп жатканыңызда, тобокелдиктерди баалаңыз: эгер автоматика баарын алмаштыра баштаса, эмне болот - бул кырсыкка салыштырмалуу андан да жаман абалга алып келбейби? Балким, кандайдыр бир жерде автоматташтыруу менен нөөмөттөгү инженердин реакциясынын ортосунда акылга сыярлык компромиссти колдонуу керек, ал чыныгы сүрөткө баа берип, бир нерсени жеринде алмаштыруу керекпи же "ооба, бирок азыр эмес" деп түшүнөт.
Перфекционизм менен чыныгы күч-аракеттин, убакыттын, акчанын ортосундагы акылга сыярлык компромисс, сиз акыры ээ боло турган схемага жумшай аласыз.
Бул текст Александр Демидовдун конференциядагы докладынын жаңыртылган жана кеңейтилген версиясы .
Source: www.habr.com