Топ факапов Циан

Добро свима! 

Моје име је Никита, ја сам вођа тима инжењерског тима Циан. Једна од мојих обавеза у компанији је да смањим број инцидената везаних за инфраструктуру у производњи на нулу.
Оно о чему ће бити речи у наставку донело нам је много бола, а сврха овог чланка је да спречи друге људе да понове наше грешке или да барем умање њихов утицај. 

Преамбула

Давно, када се Циан састојао од монолита, а још није било наговештаја микросервиса, мерили смо доступност ресурса проверавањем 3-5 страница. 

Одговарају - све је у реду, ако дуго не одговарају - упозорење. Колико дуго су морали да буду ван посла да би се то сматрало инцидентом, одлучивали су људи на састанцима. Тим инжењера је увек био укључен у истрагу инцидента. Када је истрага завршена, написали су обдукцију – својеврсни извештај мејлом у формату: шта се догодило, колико је трајало, шта смо урадили у овом тренутку, шта ћемо радити у будућности. 

Главне странице сајта или како разумемо да смо дотакли дно

 
Да бисмо некако разумели приоритет грешке, идентификовали смо најкритичније странице сајта за пословну функционалност. Користећи их, рачунамо број успешних/неуспешних захтева и временских ограничења. Овако меримо време непрекидног рада. 

Рецимо да смо сазнали да постоји велики број супер важних делова сајта који су одговорни за главну услугу – претраживање и слање огласа. Ако број неуспешних захтева прелази 1%, ово је критичан инцидент. Ако у року од 15 минута током ударног времена стопа грешке пређе 0,1%, онда се ово такође сматра критичним инцидентом. Ови критеријуми покривају већину инцидената; остали су ван оквира овог чланка.

Најбољи најбољи инциденти Циан

Дакле, дефинитивно смо научили да утврдимо чињеницу да се инцидент догодио. 

Сада је сваки инцидент детаљно описан и одражен у епу Ћира. Успут: за ово смо покренули посебан пројекат, назван ФАИЛ - у њему се могу стварати само епови. 

Ако сакупите све неуспехе у протеклих неколико година, лидери су: 

• инциденти повезани са мсскл;
• инциденти изазвани спољним факторима;
• администраторске грешке.

Погледајмо детаљније грешке администратора, као и неке друге занимљиве пропусте.

Пето место – „Довођење реда у ДНС“

Био је буран уторак. Одлучили смо да успоставимо ред у ДНС кластеру. 

Хтео сам да пренесем интерне ДНС сервере са бинд на поверднс, додељујући потпуно одвојене сервере за ово, где не постоји ништа осим ДНС-а. 

Поставили смо по један ДНС сервер на сваку локацију наших ДЦ-а и дошао је тренутак да се зоне преместе са бинд на поверднс и пребацимо инфраструктуру на нове сервере. 

У јеку селидбе, од свих сервера који су били специфицирани у вези са локалним кеширањем на свим серверима, остао је само један, који је био у дата центру у Санкт Петербургу. Овај ДЦ је првобитно проглашен некритичним за нас, али је одједном постао једна тачка неуспеха.
У том периоду пресељења пао је канал између Москве и Санкт Петербурга. Заправо смо остали без ДНС-а пет минута и вратили се када је хостер решио проблем. 

Закључци:

Ако смо раније занемаривали спољне факторе током припрема за рад, сада су и они уврштени у списак онога за шта се спремамо. И сада се трудимо да све компоненте буду резервисане н-2, а током рада можемо спустити овај ниво на н-1.

• Приликом састављања акционог плана, означите тачке у којима би сервис могао да пропадне и унапред размислите о сценарију где је све ишло „од лошег ка горем“.
• Дистрибуирајте интерне ДНС сервере на различите геолокације/центре података/рекове/прекидаче/улазе.
• На сваком серверу инсталирајте локални ДНС сервер за кеширање, који преусмерава захтеве на главне ДНС сервере, а ако је недоступан, одговараће из кеша. 

Четврто место - „Чишћење ствари у Нгинк-у“

Једног лепог дана, наш тим је одлучио да нам је „довољно овога“ и почео је процес рефакторисања нгинк конфигурација. Главни циљ је да се конфигурације доведу у интуитивну структуру. Раније је све било „историјски утврђено” и није имало никакву логику. Сада је сваки сервер_наме премештен у датотеку истог имена и све конфигурације су распоређене у фасцикле. Иначе, конфигурација садржи 253949 редова или 7836520 карактера и заузима скоро 7 мегабајта. Највиши ниво структуре: 

Нгинк структура

├── access
│   ├── allow.list
...
│   └── whitelist.conf
├── geobase
│   ├── exclude.conf
...
│   └── geo_ip_to_region_id.conf
├── geodb
│   ├── GeoIP.dat
│   ├── GeoIP2-Country.mmdb
│   └── GeoLiteCity.dat
├── inc
│   ├── error.inc
...
│   └── proxy.inc
├── lists.d
│   ├── bot.conf
...
│   ├── dynamic
│   └── geo.conf
├── lua
│   ├── cookie.lua
│   ├── log
│   │   └── log.lua
│   ├── logics
│   │   ├── include.lua
│   │   ├── ...
│   │   └── utils.lua
│   └── prom
│       ├── stats.lua
│       └── stats_prometheus.lua
├── map.d
│   ├── access.conf
│   ├── .. 
│   └── zones.conf
├── nginx.conf
├── robots.txt
├── server.d
│   ├── cian.ru
│   │   ├── cian.ru.conf
│   │   ├── ...
│   │   └── my.cian.ru.conf
├── service.d
│   ├── ...
│   └── status.conf
└── upstream.d
    ├── cian-mcs.conf
    ├── ...
    └── wafserver.conf

Постало је много боље, али у процесу преименовања и дистрибуције конфигурација, неке од њих су имале погрешну екстензију и нису биле укључене у директиву инцлуде *.цонф. Као резултат тога, неки домаћини су постали недоступни и вратили су 301 на главну страницу. Због чињенице да код одговора није био 5кк/4кк, то се није приметило одмах, већ тек ујутру. Након тога смо почели да пишемо тестове за проверу инфраструктурних компоненти.

Закључци: 

• Правилно структурирајте своје конфигурације (не само нгинк) и размислите о структури у раној фази пројекта. На овај начин ћете их учинити разумљивијим тиму, што ће заузврат смањити ТТМ.
• Напишите тестове за неке инфраструктурне компоненте. На пример: провера да ли сва кључна имена сервера дају тачан статус + тело одговора. Биће довољно да имате при руци само неколико скрипти које проверавају основне функције компоненте, како се не бисте грчевито сећали у 3 сата ујутру шта још треба проверити. 

Треће место - „Одједном је понестало простора у Касандри“

Подаци су стално расли, и све је било у реду све до тренутка када је поправка великих кућишта почела да пропада у кластеру Касандра, јер на њима није могло да функционише збијање. 

Једног олујног дана грозд се скоро претворио у бундеву, наиме:

• у кластеру је остало око 20% укупног простора;
• Немогуће је у потпуности додати чворове, јер чишћење не пролази након додавања чвора због недостатка простора на партицијама;
• продуктивност постепено опада јер сабијање не функционише; 
• Кластер је у хитном режиму.

Излаз - додали смо још 5 чворова без чишћења, након чега смо почели да их систематски уклањамо из кластера и поново улазимо у њих, као празне чворове којима је понестало простора. Потрошено је много више времена него што бисмо желели. Постојао је ризик од делимичне или потпуне недоступности кластера. 

Закључци:

• На свим цассандра серверима не би требало да буде заузето више од 60% простора на свакој партицији. 
• Требало би да се учитавају на највише 50% процесора.
• Не треба заборавити на планирање капацитета и потребно је да га добро размислите за сваку компоненту, на основу њених специфичности.
• Што више чворова у кластеру, то боље. Сервери који садрже малу количину података се брже преоптерећују, а такав кластер је лакше оживети. 

Друго место - „Подаци су нестали из складишта кључ-вредност конзула“

За откривање услуге, ми, као и многи, користимо конзул. Али ми такође користимо његов кључ/вредност за плаво-зелени изглед монолита. У њему се чувају информације о активним и неактивним узводним линијама које мењају места током примене. У ту сврху је написана служба за распоређивање која је сарађивала са КВ. У неком тренутку подаци из КВ су нестали. Враћено из меморије, али са бројним грешкама. Као резултат тога, током отпремања, оптерећење на узводним каналима је било неравномерно распоређено и добили смо много 502 грешака због преоптерећења позадинских делова на ЦПУ-у. Као резултат тога, прешли смо са конзула КВ на постгрес, одакле их више није тако лако уклонити.  

Закључци:

• Услуге без икаквог овлашћења не би требало да садрже податке критичне за рад сајта. На пример, ако немате овлашћење у ЕС-у, било би боље да забраните приступ на нивоу мреже са свих места где није потребан, оставите само оне неопходне, а такође подесите ацтион.деструцтиве_рекуирес_наме: труе.
• Вежбајте свој механизам за прављење резервних копија и опоравак унапред. На пример, унапред направите скрипту (на пример, у Питхон-у) која може да направи резервну копију и врати.

Прво место - "Капетан Неочито" 

У неком тренутку смо приметили неравномерну расподелу оптерећења на нгинк узводно у случајевима где је било 10+ сервера у позадини. Због чињенице да је роунд-робин слао захтеве од 1. до последњег узводног по реду, а свако нгинк поновно учитавање је почињало изнова, први упстреамови су увек добијали више захтева од осталих. Као резултат тога, радили су спорије и цео сајт је патио. То је постајало све уочљивије како се повећавао промет. Једноставно ажурирање нгинк-а да би се омогућило насумично није функционисало - морамо поново да урадимо гомилу луа кода који није успео у верзији 1.15 (у том тренутку). Морали смо да закрпимо наш нгинк 1.14.2, уводећи насумичну подршку у њега. Ово је решило проблем. Ова грешка побеђује у категорији „Неочигледност капетана“.

Закључци:

Било је веома занимљиво и узбудљиво истражити ову грешку). 

• Организујте своје праћење тако да вам помаже да брзо пронађете такве флуктуације. На пример, можете да користите ЕЛК да надгледате рпс на сваком позадинском делу сваког узводног тока, да пратите њихово време одговора са тачке гледишта нгинк-а. У овом случају, ово нам је помогло да идентификујемо проблем. 

Као резултат тога, већина неуспеха је могла да се избегне са скрупулознијим приступом ономе што радите. Увек се морамо сећати Марфијевог закона: Све што може поћи наопако, поћи ће наопако, и на основу тога изградити компоненте. 

Извор: ввв.хабр.цом