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

Браво на всички! 

Казвам се Никита, аз съм ръководител на инженерния екип на Cian. Една от моите отговорности в компанията е да намаля до нула броя на инцидентите, свързани с инфраструктурата в производството.
Това, което ще бъде обсъдено по-долу, ни причини много болка и целта на тази статия е да попречи на други хора да повтарят нашите грешки или поне да минимизира тяхното въздействие. 

предисловие

Преди много време, когато Cian се състоеше от монолити и все още нямаше намеци за микроуслуги, измервахме наличността на ресурс, като проверявахме 3-5 страници. 

Те отговарят - всичко е наред, ако не отговарят дълго време - предупреждение. Колко време трябва да отсъстват от работа, за да се счита това за инцидент, се решаваше от хората на срещи. Екип от инженери винаги е участвал в разследването на инцидента. Когато разследването приключи, те написаха postmortem - един вид доклад по имейл във формат: какво се е случило, колко време е продължило, какво сме правили в момента, какво ще правим в бъдеще. 

Основните страници на сайта или как разбираме, че сме ударили дъното

 
За да разберем по някакъв начин приоритета на грешката, идентифицирахме най-критичните страници на сайта за бизнес функционалността. Използвайки ги, ние отчитаме броя на успешните/неуспешните заявки и изчакванията. Ето как измерваме времето за работа. 

Да кажем, че открихме, че има редица супер важни раздели на сайта, които отговарят за основната услуга - търсене и изпращане на реклами. Ако броят на неуспешните заявки надвишава 1%, това е критичен инцидент. Ако в рамките на 15 минути по време на най-гледаното време процентът на грешка надвиши 0,1%, тогава това също се счита за критичен инцидент. Тези критерии обхващат повечето от инцидентите; останалите са извън обхвата на тази статия.

Топ най-добрите инциденти Cian

Така че определено се научихме да определяме факта, че се е случил инцидент. 

Сега всеки инцидент е описан подробно и отразен в епоса на Джира. Между другото: за това започнахме отделен проект, наречен FAIL - в него могат да се създават само епоси. 

Ако съберете всички провали през последните няколко години, лидерите са: 

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

Нека разгледаме по-подробно грешките на администраторите, както и някои други интересни неуспехи.

Пето място - „Поставяне на нещата в ред в DNS“

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

Исках да прехвърля вътрешни DNS сървъри от bind към powerdns, като разпределя напълно отделни сървъри за това, където няма нищо освен DNS. 

Поставихме по един DNS сървър във всяко местоположение на нашите DC и дойде моментът да преместим зоните от bind към powerdns и да превключим инфраструктурата към нови сървъри. 

В разгара на преместването, от всички сървъри, които бяха посочени в локалните кеширащи връзки на всички сървъри, остана само един, който беше в центъра за данни в Санкт Петербург. Този DC първоначално беше обявен за некритичен за нас, но изведнъж се превърна в единствена точка на повреда.
По време на този период на преместване каналът между Москва и Санкт Петербург падна. Всъщност бяхме оставени без DNS за пет минути и се върнахме, когато хостът отстрани проблема. 

Изводи:

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

• Когато изготвяте план за действие, маркирайте точките, в които услугата може да се провали, и помислете предварително за сценарий, при който всичко върви „от лошо към по-лошо“.
• Разпределете вътрешните DNS сървъри в различни геолокации/центрове за данни/ракове/суичове/входове.
• На всеки сървър инсталирайте локален кеширащ DNS сървър, който пренасочва заявките към основните DNS сървъри и ако е недостъпен, ще отговаря от кеша. 

Четвърто място - „Поставяне на нещата в ред в Nginx“

Един прекрасен ден нашият екип реши, че „имаме достатъчно от това“ и процесът на преработване на конфигурациите на nginx започна. Основната цел е да се приведат конфигурациите в интуитивна структура. Преди това всичко беше „исторически установено“ и не носеше никаква логика. Сега всяко server_name е преместено във файл със същото име и всички конфигурации са разпределени в папки. Между другото, конфигурацията съдържа 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

Стана много по-добре, но в процеса на преименуване и разпространение на конфигурации, някои от тях имаха грешно разширение и не бяха включени в директивата *.conf за включване. В резултат на това някои хостове станаха недостъпни и върнаха 301 на главната страница. Поради факта, че кодът за отговор не беше 5xx/4xx, това не се забеляза веднага, а чак на сутринта. След това започнахме да пишем тестове за проверка на инфраструктурни компоненти.

Изводи: 

• Структурирайте правилно вашите конфигурации (не само nginx) и обмислете структурата на ранен етап от проекта. Така ще ги направите по-разбираеми за екипа, което от своя страна ще намали TTM.
• Напишете тестове за някои инфраструктурни компоненти. Например: проверка дали всички ключови server_names дават правилния статус + тяло на отговора. Ще бъде достатъчно просто да имате под ръка няколко скрипта, които проверяват основните функции на компонента, за да не си спомняте трескаво в 3 сутринта какво друго трябва да се провери. 

Трето място - „Внезапно свърши мястото в Касандра“

Данните растяха стабилно и всичко беше наред до момента, в който ремонтът на големи касетни пространства започна да се проваля в клъстера Cassandra, защото уплътняването не можеше да работи върху тях. 

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

• имаше около 20% от общото пространство, останало в клъстера;
• Невъзможно е пълното добавяне на възли, тъй като почистването не преминава след добавяне на възел поради липса на място в дяловете;
• производителността постепенно намалява, тъй като уплътняването не работи; 
• Клъстерът е в авариен режим.

Изход - добавихме още 5 възела без почистване, след което започнахме систематично да ги премахваме от клъстера и да ги въвеждаме отново, като празни възли, които са изчерпали мястото си. Отделихме много повече време, отколкото бихме искали. Имаше риск от частична или пълна недостъпност на клъстера. 

Изводи:

• На всички сървъри cassandra не трябва да се заема повече от 60% от пространството на всеки дял. 
• Те трябва да се зареждат на не повече от 50% процесор.
• Не трябва да забравяте за планирането на капацитета и трябва да го обмислите за всеки компонент, въз основа на неговите специфики.
• Колкото повече възли в клъстера, толкова по-добре. Сървърите, съдържащи малко количество данни, се претоварват по-бързо и такъв клъстер е по-лесен за съживяване. 

Второ място - „Данните изчезнаха от хранилището за ключ-стойност на консула“

За откриване на услуги ние, както много други, използваме консул. Но ние също използваме неговия ключ-стойност за синьо-зелено оформление на монолита. Той съхранява информация за активни и неактивни възходящи потокове, които сменят местата си по време на внедряването. За тази цел беше написана услуга за внедряване, която взаимодейства с KV. В един момент данните от KV изчезнаха. Възстановен по памет, но с редица грешки. В резултат на това по време на качването натоварването върху възходящите потоци беше разпределено неравномерно и получихме много 502 грешки, дължащи се на претоварване на задните части на процесора. В резултат на това се преместихме от консул KV към postgres, откъдето вече не е толкова лесно да ги премахнете.  

Изводи:

• Услугите без никакво разрешение не трябва да съдържат данни, критични за работата на сайта. Например, ако нямате разрешение в ES, би било по-добре да откажете достъп на мрежово ниво отвсякъде, където не е необходимо, оставете само необходимите и също така задайте action.destructive_requires_name: true.
• Практикувайте своя механизъм за архивиране и възстановяване предварително. Например, направете предварително скрипт (например в Python), който може да архивира и възстановява.

Първо място - „Капитан Неочевиден“ 

В даден момент забелязахме неравномерно разпределение на натоварването върху nginx upstreams в случаите, когато имаше 10+ сървъра в бекенда. Поради факта, че round-robin изпращаше заявки от 1-ви до последния upstream по ред и всяко презареждане на nginx започваше отначало, първите upstream-и винаги получаваха повече заявки от останалите.В резултат на това те работеха по-бавно и целият сайт страдаше. Това става все по-забележимо с нарастването на трафика. Простото актуализиране на nginx, за да се активира произволно, не работи - трябва да преработим куп lua код, който не излетя на версия 1.15 (в този момент). Трябваше да закърпим нашия nginx 1.14.2, като въведохме произволна поддръжка в него. Това реши проблема. Този бъг печели категорията „Капитан неочевидност“.

Изводи:

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

• Организирайте наблюдението си така, че да ви помага бързо да откривате такива колебания. Например, можете да използвате ELK, за да наблюдавате rps на всеки бекенд на всеки upstream, да наблюдавате тяхното време за реакция от гледна точка на nginx. В този случай това ни помогна да идентифицираме проблема. 

В резултат на това повечето от провалите биха могли да бъдат избегнати с по-внимателен подход към това, което правите. Винаги трябва да помним закона на Мърфи: Всичко, което може да се обърка, ще се обърка, и изграждане на компоненти въз основа на него. 

Източник: www.habr.com