Топ факапов цијан

Се добро! 

Јас се викам Никита, јас сум тим лидер на инженерскиот тим Cian. Една од моите обврски во компанијата е да го сведам на нула бројот на инциденти поврзани со инфраструктурата во производството.
Она што ќе се дискутира подолу ни донесе многу болка, а целта на овој напис е да ги спречи другите луѓе да ги повторуваат нашите грешки или барем да го минимизираат нивното влијание. 

Преамбула

Многу одамна, кога Cian се состоеше од монолити, а сè уште немаше навестувања за микросервиси, ја меривме достапноста на ресурс со проверка на 3-5 страници. 

Тие одговараат - сè е во ред, ако не одговорат долго време - алармираат. Колку долго требаше да бидат надвор од работа за да се смета за инцидент, одлучуваа луѓето на состаноците. Тим од инженери секогаш бил вклучен во истрагата за инцидентот. Кога заврши истрагата, напишаа постмортам - еден вид извештај по електронска пошта во формат: што се случило, колку траело, што направивме во моментот, што ќе правиме во иднина. 

Главните страници на страницата или како разбираме дека го допревме дното

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

Да речеме, дознавме дека постојат голем број суперважни делови на страницата кои се одговорни за главната услуга - пребарување и испраќање огласи. Ако бројот на неуспешни барања надминува 1%, ова е критичен инцидент. Ако во рок од 15 минути за време на ударното време стапката на грешка надмине 0,1%, тогаш ова исто така се смета за критичен инцидент. Овие критериуми ги покриваат повеќето инциденти, останатите се надвор од опсегот на овој член.

Топ најдобри инциденти Цијан

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

Сега секој инцидент е детално опишан и одразен во епот на Џира. Патем: за ова започнавме посебен проект, наречен FAIL - во него може да се создаваат само епови. 

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

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

Да ги разгледаме подетално грешките на администраторите, како и некои други интересни неуспеси.

Петто место - „Поставување на работите во ред во DNS“

Беше бурен вторник. Решивме да го вратиме редот во кластерот DNS. 

Сакав да префрлам внатрешни DNS сервери од bind на powerdns, доделувајќи целосно посебни сервери за ова, каде што нема ништо освен DNS. 

Поставивме по еден DNS сервер на секоја локација на нашите DC и дојде моментот да ги преместиме зоните од bind во powerdns и да ја префрлиме инфраструктурата на нови сервери. 

Во средината на движењето, на сите нешта сервериОд серверите наведени во локалните кеширачки врски, остана само еден - оној во центарот за податоци во Санкт Петербург. Овој центар за податоци првично беше прогласен за некритичен за нас, но одеднаш стана единствена точка на грешка.
Токму во овој преоден период каналот помеѓу Москва и Санкт Петербург прекина. Ефективно останавме без DNS пет минути и се опоравивме кога домаќин ги реши проблемите. 

Заклучоци:

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

• Кога изготвувате акционен план, означете ги точките каде услугата може да пропадне и однапред размислете низ сценарио каде сè отиде „од лошо на полошо“.
• Дистрибуирајте внатрешни DNS сервери низ различни геолокации/центри за податоци/лавици/прекинувачи/влезови.
• На секој сервер, инсталирајте локален DNS-сервер за кеширање, кој ги пренасочува барањата до главните DNS-сервери, а доколку е недостапен, ќе одговара од кешот. 

Четврто место - „Ставување на работите во ред во Nginx“

Еден убав ден, нашиот тим одлучи дека „ни е доста од ова“ и започна процесот на рефакторирање на конфигурациите на nginx. Главната цел е да се доведат конфигурациите до интуитивна структура. Претходно, сè беше „историски утврдено“ и не носеше никаква логика. Сега секое име на серверот е преместено во датотека со исто име и сите конфигурации се дистрибуирани во папки. Патем, конфигурацијата содржи 253949 линии или 7836520 знаци и зафаќа скоро 7 мегабајти. Највисоко ниво на структура: 

Nginx структура

├── 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

Стана многу подобро, но во процесот на преименување и дистрибуција на конфигурации, некои од нив имаа погрешна екстензија и не беа вклучени во директивата include *.conf. Како резултат на тоа, некои домаќини станаа недостапни и го вратија 301 на главната страница. Поради фактот што кодот за одговор не беше 5xx/4xx, тоа не беше забележано веднаш, туку само наутро. После тоа, почнавме да пишуваме тестови за проверка на инфраструктурните компоненти.

Заклучоци: 

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

Трето место - „Одеднаш остана без простор во Касандра“

Податоците постојано растеа и сè беше во ред до моментот кога поправката на големите простори на куќиштето почна да не успева во кластерот Касандра, бидејќи набивањето не можеше да работи на нив. 

Еден бурен ден кластерот за малку ќе се претворил во тиква, имено:

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

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

Заклучоци:

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

Второ место - „Податоците исчезнаа од складирањето клучеви со вредност на конзулот“

За откривање на услугата, ние, како и многумина, користиме конзул. Но, ние исто така ја користиме неговата клучна вредност за сино-зелен распоред на монолитот. Зачувува информации за активни и неактивни горе, кои ги менуваат местата за време на распоредувањето. За таа цел, беше напишана услуга за распоредување која има интеракција со KV. Во одреден момент исчезнаа податоците од КВ. Обновен од меморија, но со голем број на грешки. Како резултат на тоа, за време на прикачувањето, оптоварувањето на upstreams беше нерамномерно распределено и добивме многу 502 грешки поради преоптоварување на заднините на процесорот. Како резултат на тоа, од конзулот К.В се преселивме во постгрес, од каде веќе не е така лесно да се отстранат.  

Заклучоци:

• Услугите без никакво овластување не треба да содржат податоци клучни за работата на страницата. На пример, ако немате овластување во ES, би било подобро да го одбиете пристапот на ниво на мрежа од секаде каде што не е потребно, да ги оставите само потребните, а исто така да поставите action.destructive_requires_name: true.
• Вежбајте го механизмот за резервна копија и враќање однапред. На пример, однапред направете скрипта (на пример, во python) што може да направи резервна копија и обновување.

Прво место - „Капетан Unobvious“ 

Во одреден момент, забележавме нерамномерна распределба на оптоварувањето на nginx upstreams во случаи кога имаше 10+ сервери во задниот дел. Поради фактот што круг-робин испраќаше барања од 1-во до последното горе по ред, и секое повторно вчитување на nginx започнуваше одново, првите upstream-и секогаш добиваа повеќе барања од останатите Како резултат на тоа, тие работеа побавно и страдаше целата локација. Ова стана сè позабележително како што се зголемуваше сообраќајот. Едноставното ажурирање на nginx за да се овозможи случаен избор не функционираше - треба повторно да направиме еден куп lua код што не се активираше на верзијата 1.15 (во тој момент). Моравме да го закрпиме нашиот nginx 1.14.2, воведувајќи случајна поддршка во него. Ова го реши проблемот. Оваа грешка ја освои категоријата „Неочигледност на капетанот“.

Заклучоци:

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

• Организирајте го вашиот мониторинг така што ќе ви помогне брзо да ги најдете таквите флуктуации. На пример, можете да го користите ELK за следење на rps на секој заден дел од секоја спротиводно, да го следите нивното време на одговор од гледна точка на nginx. Во овој случај, ова ни помогна да го идентификуваме проблемот. 

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

Извор: www.habr.com