Підтримка высоконагруженного проекту



Євген Потапов ( eapotapov
Доповідь про те, що робити з проектом після того, як ми його запустили. Ви спланували архітектуру проекту, ви продумали, як у нього буде працювати інфраструктура, продумали, як будете балансувати навантаження, нарешті, його запустили. Що робити далі? Як підтримувати, як зробити так, щоб проект продовжував працювати, і як зробити так, щоб нічого, зрештою, не впало?



Для початку трохи про себе. Я з компанії «ITSumma», наша компанія займається цілодобовою підтримкою і адмініструванням вебсайтів. Зараз у нас працює 50 чоловік, ми засновані в 2008 році, ми підтримуємо більше 1000 серверів, які щодня відвідує більше 100 млн. чоловік.



Є великі проекти на підтримку, є невеликі, в основному, це російські проекти, і на підставі досвіду підтримки цих проектів я б хотів поговорити про те, що ж варто робити.


Якщо говорити про підтримку, з чого вона складається? На мій погляд, вона складається з трьох компонентів:

  1. моніторинг проекту та реагування на алерти, які приходять,
  2. організація резервування і резервного копіювання (ці штуки ми поділяємо),
  3. організація обслуговування і підтримки, власне, реагування на те, що відбувається з проектом.


Якщо говорити про моніторинг, ми всі розуміємо, що необхідний моніторинг. Потрібно зрозуміти, як і для чого його використовувати. Ми можемо розділити використання моніторингу на три етапи, як вони приходять в голову, як до них приходять люди, приходять компанії.



На першому етапі моніторинг розглядається просто як система оповіщення про стан справ з проектом. Оповіщення про проблеми на сервері — це найпростіший етап; оповіщення про проблеми, пов'язані з логікою програми, — як більш ускладнена штука, коли ми спостерігаємо, що щось не так стало з сайтом, з проектом та розуміємо це вже з якихось показників подій на сайті; і сповіщення про проблеми, пов'язаних з бізнес-показниками.



Якщо говорити про вимоги до самої системи оповіщення на будь-якому высоконагруженном проекті, то ми повинні розуміти, що, перш за все, система моніторингу повинна бути незалежна від самого проекту. Вона не повинна розташовуватися там же, де знаходиться проект, вона не повинна бути з ним пов'язана. Якщо проект впаде, система моніторингу впасти не повинна.

Система моніторингу повинна максимально швидко сповіщати вас про те, що відбувається на проекті. Якщо у вас сталася якась аварія, або якщо вам здається, що аварія скоро відбудеться, оповіщення вам про те, що щось відбувається, не повинно прийти через тривалий час, ви повинні дізнатися про це якомога швидше. І ви повинні бути впевнені в тому, що ви надійно отримуєте інформацію про те, що відбувається з проектом. Тобто ви повинні точно розуміти, що коли будуть досягнуті критичні показники, які ви встановили за проектом, або коли станеться якась аварія на проекті, ви отримаєте відповідне повідомлення.



Якщо говорити про рівні оповіщення. Перший рівень — це проблеми на сервері, коли ми просто, самим базовим чином дивимося на якісь фізичні показники, показники, пов'язані з софтом на операційній системі, з базовим софтом. Другий — проблеми на рівні програми, коли ми дивимося, як підсистема програми взаємодіє з іншими підсистемами, як вони взаємодіють із зовнішніми сервісами, і що відбувається там. І третій рівень оповіщення — це про проблеми на рівні бізнес-логіки.



Проблеми на сервері. Найпростіші штуки, які можна там моніторити, це:

  • статистика по навантаженні на центральний процесор, де ми дивимося на навантаження на сам процесор і на непрямі показники за цією навантаженні — load average — ковзна середня;
  • статистика по навантаженню на дискову підсистему;
  • статистика використання оперативної пам'яті і swap.
Якщо говорити про всіх показниках на сервері, які ми можемо замониторить, ці три штуки в першу чергу можуть сказати нам про те, що з сервером відбувається щось не те. CPU зростає при зростанні трафіку або неоптимальному коді. Навантаження на дискову підсистему найчастіше відбувається при неоптимальному взаємодії з базою даних. Використання оперативної пам'яті різко збільшується, і пам'ять йде в swap, якщо у вас зростає трафік, якщо у вас знову ж якийсь неоптимальний код.



Статистика по серверному софту. Ставимо оповіщення на падіння і злети числа запитів на сервер. Дивимося зовні на перевірки доступності сайту, причому, якщо ми встановлюємо зовнішні перевірки на доступність, ми повинні перевіряти не тільки час відповіді сторінок і коду відповіді, але часто трапляються помилки з боку розробки, коли замість http 502, сервер віддає http 200, і сторінка, начебто, видає помилку, але для системи моніторингу, для пошукових рушіїв, вона продовжує вважатися валидной, нормальної сторінкою, в якій просто написаний текст помилки. Тому ми рекомендуємо:

  1. додатково до перевірок часу і коду відповіді, дивитися розмір відповіді сторінки, коли зазвичай він у вас не змінюється в часі, і якщо щось відбувається, пов'язане з великою-великою аварією, розмір, найчастіше, різко падає вниз;
  2. за допомогою вже з'явилися тулзов типу CasperJS дивитися на час безпосередньо рендеринга сторінок. Дуже часто ми бачимо, як на деяких зовнішніх сервісах (в останній рік кілька разів цим грішив сервіс коментів Cackle), рендеринг різко уповільнювався, тобто сторінки генеруються, які ви перевіряєте на сервері, проте в браузері у людей з'являється лише шматок якихось картинок, до кінця вони не погружаюфтся.


Оповіщення про проблеми на рівні програми. В першу чергу, слід замониторить число помилок рівня додатки. Так, є логи, в які можна подивитися, але найчастіше на будь-яких проектах, рано чи пізно, в прагненні робити якісь нові фічі, бракує часу розібратися з тією кількістю нотификационных повідомлень, про яких приходить інформація від додатка. Замість того щоб розбиратися з цим потоком, один з простих методів — це спостерігати за кількістю таких повідомлень в хвилину. Тобто ми дивимося, що у нас десь 100-200 таких повідомлень в хвилину, потім через якийсь черговий викладення у нас різко підскакує це число до 2000-3000, тобто нас не цікавить окремий рядок, нас цікавить загальна велика кількість з цих сповіщень.

Число звернень до підсистем/«вузлів». Нехай у вас є проект, який ефективно використовує систему кешування і рідко звертається до бази даних. Можна і варто замониторить число звернень до бази даних, селектов, инсертов, апдейтів, делитов і далі дивитися на зміни. В процесі, якщо у вас немає різких стрибків трафіку, ця кількість буде у вас триматися приблизно рівним. Якщо у вас щось відбувається з системою кешування, ви побачите сплеск на таких запитах і зрозумієте, що відбувається щось не те, і слід розслідувати. Таке слід зробити до будь підсистемам, і вже далі, виходячи з інформації, яку ви зберете, поставити якісь додаткові алерти.

Якщо у вас є якісь зовнішні сервіси, я під ними розумію бази даних, сервіси, розташовані на інших серверах на вашому майданчику, зовнішні API, то слід обов'язково замониторить взаємодія з цими сервісами. Особливо з зовнішніми API. Ми всі вважаємо, що це у нас проблеми, а у великих компаніях все роблять класно і добре, але наш досвід взаємодії клієнтів з фейсбучным API говорить про те, що баги там бувають дуже часто, час відповіді різко збільшується, і ви можете вважати, що сайт починає гальмувати у вас, а на ділі це різко погіршився взаємодія з якимось зовнішнім API, про який ми навіть не підозрювали, що воно може погіршитися. Відповідно, ми ставимо на моніторинг час взаємодії тих важливих запитів, які нам потрібні, і при стрибках у часі відповіді у цих запитах починаємо розслідувати, що сталося з нашим додатком, чи не стало воно працювати гірше.



Є така прикольна штука, яку чомусь дуже рідко роблять (що дивно), — це моніторинг бізнес-логіки.

Коли ми моніторимо сервер, у нас є мільйон показників, які ми можемо замониторить, і ми можемо про якийсь із показників подумати, що він зараз не важливий: «Я не буду закривати його алертом, я не можу зрозуміти, який у нього може бути критичне значення, я не можу зрозуміти, на що мені реагувати». І рано чи пізно, коли цей показник спливе, може статися так, що у вас немає алерта на таку аварію, а аварія трапилася. Всі ці мільйон показників, зрештою, перетворюються в проблеми з тим, для чого існує цей додаток. Додаток існує, умовно кажучи, починаючи з кількості зароблених грошей за день, кількості користувачів, які зробили якісь дії, до простих штук — кількість покупок на сайті, кількість замовлень, оформлених на сайті, кількість постів на сайті. Всі ці штуки досить просто замониторить, особливо якщо ви розробник, і поставити на алерти вже з цієї точки зору. Тоді, навіть якщо ми пропустили моніторинг та нотифікації з боку серверного ПЗ, нехай у нас почало гальмувати залізо, і з-за цього у нас стали відвалюватися користувачі на якихось своїх діях, ми зрозуміємо, що це падіння трафіку або дій сталося з якоїсь причини, і зможемо вже самі очима розслідувати графіки, розслідувати причини того, що відбувається і розібратися.

Друга річ, яку варто часто робити — це емуляція користувача логіки програми. Ми часто моніторимо серверні штуки, ми моніторимо готельні скрипти на те, що вони відповідають. Але, для прикладу, дуже круто моніторити, якщо у нас є логін на сайт, якщо у нас користувач приходить і реєструється, далі заповнює форму, отримує лист з реєстраційної посиланням, натискає на цю посилання і заходить на сайт. У нас є, щонайменше, штук п'ять місць, де може щось зламатися. Якщо ми кожне з цих п'яти місць моніторимо окремо, ми не впевнені, що ця вся послідовність працює в цілому. Створити скрипт, який зайде на сайт, заповнить форму, засабмитит постом дані, потім створити скрипт, який перевірить пошту і клацне на посилання, яка там була, просто перевірить, що куки відновилися — ця робота технічно на дня два, а контроль, який від цього вийде, значно перевищує витрати на створення цього скрипта. Тому я пропоную, щоб ця штука для більшості критичних функцій на сайті була обов'язковою.



Інша річ, яку ми не зовсім правильно бачимо в моніторингу, — це коли оповіщення встановлюються на критичні показники вже близькі до страшну-страшну біду. Люди ставлять оповіщення на завантаження процесорів на 99% протягом 5-10 хвилин. Той момент, коли до вас приходять такі дані, ви технічно зробити практично нічого не можете, тобто ви вже маєте у себе завантажений сервер, ви вже маєте у себе впало додаток і вам треба в авралі, у пожежі вирішити, що ж з цим робити. На старті проекту, після якогось часу запуску, і після того, як ви зможете проаналізувати, який характер у вашого трафіку, ви можете зрозуміти характер навантаження. Наприклад, якщо у вас процесор завантажений на 30%, не потрібно ставити оповіщення на 90%, не потрібно ставити оповіщення на 99%, потрібно для себе вибрати якісь ключові точки, на яких вам потрібно приймати нові рішення. Тобто алерт на 50%, і ви розумієте, що у вас зазвичай була навантаження в 30%, до якої ви звикли, а тепер 50%. Це не страшно з точки зору роботи сервера, але вам пора подумати про те, яким буде подальше зростання, і коли ви дійдете до 70% і т. д. В таких випадках ви отримаєте запас часу, коли ви зможете вирішити, що ж робити, чи можете ви з цим ще жити, або вже пора думати, як змінювати архітектуру, може, докупити нового заліза, може, треба що-небудь зробити з кодом, якщо останнім часом щось сталося, із-за чого він став відповідати довше і т. д.



Моніторинг як система аналізу. Якщо ми до цього говорили, що моніторинг — це система оповіщення, то вибираючи систему моніторингу, ми повинні зрозуміти, що це не тільки система оповіщення, але це і система аналізу, що:

  • a) повинна зберігати максимально можливу кількість даних;
  • b) повинна дати можливість швидко вибрати ці дані за потрібний період;
  • c) вміти їх швидко відобразити в потрібному нам вигляді.


Крім іншого, ця штуковина повинна володіти можливістю порівняння однотипних даних з різних серверів, якщо ми говоримо про те, що у нас багатоплатформенна, многосерверная система. Тому що, якщо у нас є п'ять однотипних серверів, і ми дивимося на кожен моніторингу в окремо, ми можемо не помітити того, що один сервер став відхилятися від інших на 30%, але якщо ми згрупуємо статистики по всіх п'яти серверів разом, то ми це побачимо.

Система моніторингу повинна володіти порівняння поточних даних з історичними даними, тому що якщо у нас йде невеликий спад або невелике зростання протягом довгого часу, просто дивлячись оком на графік, можна на це не звернути уваги. Якщо ми виберемо дві лінії — одну поточну, а другу, наприклад, як це було місяць тому, то ми побачимо справжню різницю, і ми зможемо вже зрозуміти, що відбувається.

Швидка вибірка великого діапазону історичних даних. Мається на увазі те, що у нас фактично записується величезну кількість даних, і сам по собі моніторинг — це высоконагруженное додаток. Якщо моніторинг зберігає ці дані, він повинен мати можливість ці дані вивантажити.

У доповіді на RootConf'е ми з колегою розглядали приклади тих систем моніторингу, які доступні в даний час, і якщо говорити про те, що можна використовувати, то більш-менш ready це класичний Zabbix і Graphite. Але що цікаво, до чого я кажу про третю частину з швидкою вибіркою великого діапазону історичних даних, — у нас, якщо дивитися з нашим клієнтам, десь близько 70% сидить на Zabbix'е і близько 20% сидить на Graphite, і будь-яка нода з Graphite'ом займається тим, що практично забита на 100% по процесору. Тобто система хороша для запису даних, вона хороша для їх відображення, але регулярно виникають проблеми з тим, що моніторинг просто не може промалювати те, що від нього хочуть. Тобто система повинна зробити це швидко, а отримати це швидко не можна.



Додаткова штука, якщо ви будете вибирати систему моніторингу, дуже була б корисна — це складна агрегація метрик. Найчастіше якісь з метрик на проекті можуть бути відносно з шумом, цей шум необхідно якимось чином мінімізувати, отримати ковзну середню, подивитися по запитам перцентиль, яку кількість часу виповнилося 99% запитів, згрупувати запити щодо мінімального протягом часу і т. д.



Крім цього, моніторинг потрібно уявляти собі як систему для прийняття рішень.

Тобто у нас є моніторинг як система оповіщення, у нас є моніторинг як система для аналізу того, чому у нас трапилася проблема, і для розуміння того, як цю проблему уникнути, і найголовніше у нас виходить, ми повинні використовувати систему моніторингу як штуку, яка нам дозволить:

  • a) зрозуміти, як аварія сталася, і що зробити такого, щоб це не повторилося;
  • b) подивитися на те, як система буде розвиватися в майбутньому;
  • c) подивитися на те, як зробити так, щоб уникнути помилок, які вже були.


Якщо говорити про доступні рішення, дійсно хороших, які працюють на невеликому проекті і не коштують занадто дорого в плані впровадження, я вважаю, що потрібно використовувати SaaS сервіси. Вгорі перераховано три сервісу, їх необов'язково використовувати всі вони приблизно однакові. Для невеликої кількості серверів вони коштують недорого. І найголовніше, вони не витратять вашого часу на їх інтеграцію.

Складний збір даних. Я б зараз звернув увагу на Graphite, але вам доведеться добряче помучитися, вирішуючи, як там зберігати дані. Якщо у вас дуже складна система, якщо у вас дуже складні дані, можна подумати про те, щоб зробити свою систему або сильно кастомизировать open source, але потрібно розуміти, що це дуже-дуже великий внесок у інвестиції в розвиток цієї системи.

Ми використовуємо власну систему, тому що у нас історично склалося, що інфраструктура дуже гетерогенна, у нас високі вимоги до того, як вона повинна підтримуватися, і як повинні скалироваться проблеми всередині компанії. Ми розробку цієї штуковини ведемо з 2008 року. У нас є два розробника, які цим постійно займаються, і у нас є дуже-дуже багато побажань від адмінів, як цю штуку далі змінювати. Єдина причина, по якій ми використовуємо цю штуку, а не Graphite або Zabbix, це те, що ми розуміємо, чого ми можемо отримати від системи моніторингу. Ми розуміємо, як її доопрацювати, і ми можемо це зробити або не можемо цього зробити. Але і, крім усього, потрібно зрозуміти, що до системи моніторингу ви звикаєте, і в той момент, коли ви її вибрали, чим довше ви використовуєте одну і ту ж систему, тим довше після цього вам не захочеться з неї злізти, навіть якщо ви їй не задоволені.



Переходимо до другої частини. Поговоримо про резервне копіювання і резервування.

Насамперед, я хотів би поговорити про резервне копіювання. По суті, ця штуковина дуже часто серед наших клієнтів і серед тих, кого ми бачимо, здається простою річчю, яка сама по собі працює, над якою навіть не варто думати. Однак, роблячи резервне копіювання, потрібно зрозуміти, що:

  • Резервне копіювання створює навантаження на сервер.
  • Для вашого проекту може зіграти велику роль регулярність зняття резервних копій. Наприклад, у вас постійно величезна кількість користувачів роблять якусь дію, нехай це сервіс, де люди за гроші обробляють фотографії. Якщо у вас бекапи робляться раз на день, дані пропали, і ви відновилися з 20-тичасовой давності, ви все одно отримаєте величезну кількість проблем, пов'язаних з тим, що користувачі будуть говорити: «OK, а де мої дані за останні 20 годин?».
  • Потрібно розуміти, що час відновлення з резервної копії також грає роль. Тобто ви можете робити дамп, який робиться швидко, але цей дамп в деяких випадках може виливатися дуже довго.


Процес зняття резервної копії:

  1. Сам по собі важка процедура.
  2. Резервні копії з-за цього краще всього створювати c резервних машин, не створюючи навантаження на продакшиновых машинах.
  3. Потрібно розуміти те, що потрібно резервувати. Класична штука — бэкапим часто базу. «А ось у нас дуже багато статики, яку генерує користувачі, її ми краще будемо генерувати раз в день». Але який сенс раз в кілька годин бэкапить базу, коли ви з неї відновити, у вас не буде статики, і користувачі точно також будуть незадоволені, як і раніше? Тобто вони поїдуть, умовно кажучи. У вас сервіс другий ВКонтактик, ви дропнули базу, у вас впав сервер, і ви підняли з резервної копії бази, у вас є посилання на фотографії, але немає самих фотографій...
  4. Класична штука. Бекап без регулярної процедури відновлення — не бекап. Дуже часто ми бачимо, коли люди організували бекап, вони його завантажують, і вони вважають, що цього достатньо. У чотирьох з десяти випадків з резервної копії, яка є, відновитися без перевірок, виявляється, не можна. Повинна бути в організації створена регулярна процедура відновлення, регулярний план навчань, за якими ви в задану дату починаєте відновлюватися з резервної копії, перевіряти, за скільки ви можете це зробити, наскільки актуальні будуть ваші дані, і наскільки буде працездатний сайт після відновлення з резервної копії.


Резервні копії баз.

Використовуємо slave-сервер тільки як резервну копію на випадок аварії майстер-сервера. Є класична історія падіння Ощадбанку кілька років тому, коли вони використовували slave-сервер як резервну копію і більше нічого з ним не робили. Тобто не було бекапів, був лише slave, а потрібно розуміти, що slave приймає всі запити, і якщо прийшов чоловік на майстер-сервер і сказав: «Видалити всі з майстер-сервера», slave отримає точно таку ж команду.

На деяких базах, я не можу сказати за Postgres, я бачив такі штуковини на MySQL, є можливість зробити slave з відкладеним оновленням. Це невеликий хак, який іноді допомагає. Тобто ви робить відкладене оновлення slave десь хвилин на 30, і у вас вже є час, коли ви розумієте, що випадково зробили дроп на майстер-базі, ви можете різко перервати репліку і переключитися на slave замість того, щоб робити довгу процедуру відновлення бази.

Hot-backup-служби для регулярного зовнішнього резервного копіювання. Тобто у нас є slave для захисту від аварії, і hot-backup для захисту від людського фактора.



Мінімум одну копію ми зберігаємо в межах тієї ж майданчики, де знаходимося, щоб швидко її викачувати, і мінімум одну копію ми зберігаємо на зовнішній майданчику для відновлення глобальної аварії.

Не можна зберігати копію в тому ж місці, де ви очікуєте, що може статися аварія, тому що коли цілком впаде дата-центру в Hetzner'е, ви не зможете відновитися, якщо він впаде на кілька днів. Всі ці кілька днів, ви, навіть володіючи правильним резервних копій, навіть роблячи правильні процедури, будете просто чекати, поки не підніметься хостинг. При цьому потрібно розуміти, що аварії в хостингах — це не завжди питання 10, 15, 20-ти хвилин. У Amazon за останні п'ять років було чотири аварії, найдовша з яких тривав 48 годин, наступна тривала 24 години, наступна тривала 16 годин, наступна тривала близько 10-ти годин. Вони кожен раз говорили, що «ми дуже вибачаємося, повернемо вам гроші, які коштував хостинг в цей час», але зрозуміло, що це не можна порівняти з тими втратами, які були на ділі. Тому зберігати бекапи ідеально ще в іншому місці, звідки ви знаєте, що якщо ця площадка впаде, ви зможете відновитися.



Контент. Складна-складна тема, особливо, якщо у вас його багато. Якщо у вас його не багато, робимо регулярнные Rsync, робимо снэпшоты. Якщо у вас його багато, то краще всього цю штуку реалізувати відразу на рівні програми. Нехай у вас заливається фотографія, якийсь файл, який заливається або обробляється користувачем. Після видачі даних контенту користувачеві зробіть, щоб в даний момент цей файл дублювався на резервну копію. Вам не потрібно буде тоді регулярно копіювати всю пачку змін раз на день, раз в годину і т. д. Одну дію, але просте, воно робиться непомітно для користувача, тому що контент йому вже віддається. Просто фоном файл переливається в інше місце, в інший майданчик, яка не залежна від основної.



І дуже часта річ, яку ми бачимо, це те, що бэкапится база, бэкапится контент, і не бэкапятся конфіги. У результаті падає дата-центр, падає сервер, потрібно відновитися, ми відновлюємося з бекапів, у нас є бекап коди, бекап статики, у нас все кльово, але у нас дуже-дуже складна конфігурація веб-сервера, і наступні кілька годин команда цього проекту займається тим, що відновлює з пам'яті конфіг або намагається відновити конфіг дворічної давності.



Є резервне копіювання, є резервування, це різні речі.

Вибір майданчика для резервування.



Резервна майданчик не повинна бути пов'язана з поточним дата-центром. Ми дуже часто бачимо, коли до основного сервера береться резервний сервер у тому ж місці, тобто, умовно кажучи, той самий Hetzner, де у вас є одна машина в стійці, і друга машина в стійці виступає як резерв. Так, вона захистить від аварій самого сервера, але вона ніяк не захистить від аварій у всьому дата-центрі в цілому. Якщо ми вибираємо резервну майданчик до основної, частіше всього люди хочуть зробити так, щоб вона була дешевша, тому що вона не отримує трафік. Потрібно розуміти, що після перемикання на резервну, ви можете опинитися в такій ситуації, коли ви залишитеся з нею надовго. І якщо ви вважаєте, що на ній можна прожити годину, але на ній не вийде прожити день або більше, краще вже подумати про те, чи варто так робити.



Питання потужностей для резервування. На запуск проекту дуже не хочеться піднімати ту ж саму архітектуру, яка є на продакшне. Тобто нехай у вас десяток серверів на продакшне, для того, щоб зрозуміти резерв, вам потрібно підняти десять таких же серверів в іншому місці, і фактично нічого з ними не робити. Можна спробувати підняти не десять серверів і десять серверів, а п'ять серверів і п'ять серверів, розподілити на них трафік. Але тут ми зустрічаємося з двома питаннями:

  • перший — це синхронізація між різними дата-центрами і проблема пов'язаності між ними.
  • другий — коли трапляється аварія в одному з них, виходить, що п'ять серверів приймають трафік, який мали раніше приймати десять, і проблеми з навантаженням все одно відбуваються. Якщо у вас той майданчик померла надовго, ви знаходитесь на цих п'яти машинах у перевантаженому режимі досить довгий час.
Штука, яку часто використовують люди, це т. зв. гібридні хмара. У вас є майданчик, яка під продакшном, і у вас є в хмарах мінімальна конфігурація, здатна лише на те, щоб прийняти реплікацію з продакшн майданчики. Якщо на продакшн майданчику трапляється якась аварія, хмари скейлятся вгору для того, щоб стати такими ж, яка була майданчик, і на них перемикається трафік. В процесі довгого часу це буде трохи дорожче, ніж залізний продакшн, але в процесі використання в регулярному режимі, коли у вас аварій немає, ви на цьому резерві економите час і гроші, і при цьому не ризикуєте тим, що можна потрапити в якісь проблеми при перемиканні.



Важливі штуки при резервуванні. Перш за все, потрібно розуміти, скільки часу у вас займе це перемикання. Потрібно розуміти, наскільки цілісні дані у вас синхронізуються на резерв. І потрібно розуміти, який ризик простою при перемиканні.

Дуже-дуже складна процедура, яку люди не люблять… Перевіряти відновлення з резервних копій — це, в принципі, просто, але треба також регулярно перевіряти можливість перемикання на резервну майданчик. Можна зробити резервну майданчик і чекати тільки того моменту, коли на неї можна буде перейти. Існує мільйон варіантів, з-за чого резерв може не спрацювати. Найпростіше — просто щось не запланували при проектуванні резервної архітектури. Так, якщо ми переключаємося без аварії, і там щось буде не так, проект впаде, то це буде хоча б усвідомлений ризик. Вночі чи в якийсь тихий час, коли це можна зробити. Це краще, ніж, якщо ви, переключившись у момент аварії, дізнаєтеся про те, що у вас чогось не вистачає, якісь файли не синхронізувалися, якась база відставала і т. д.



Підводячи підсумки.

  • Slave — це не бекап.
  • Бекап в тому ж дата-центрі — це не бекап.
  • Резерв у тому ж дата-центрі — це не резерв.
  • Бекап, який не відновлювали — це не бекап.
  • Бекап без статики — це не бекап, тому що люди просто не будуть знати, що у них з контентом.
  • Якщо не вистачає місця — це не відмазка. Дуже часто ми чуємо: «Хлопці, у нас погано з бекапом, у нас зараз не вистачає місця, ми вирішимо це через тиждень». Буквально на днях, клієнти, які збиралися вирішити проблему через тиждень, втратили два сервера. Там було додаткове резервування, яке ми зробили, яке допомогло. Але буде дуже прикро, коли ви зрозумієте, що ви тиждень думали, коли у вас знайдеться час, щоб зробити бекап і взяти сервер в Hetzner'е за 60 євро з 2 Тб дисків, замість цього ви нічого не зробили і втратили дані, які коштують набагато дорожче.
  • «Я вирішу про бекап днями» — це фраза, яка веде до втрачених даних. Один крок до втрачених даних.


І важливо розуміти, що всі ці штуки не працюють, якщо немає команди, яка буде на ці штуки реагувати і ці штуки робити.

Чим повинна володіти ця команда. Команда повинна бути у вас всередині. Вона може бути трохи зовні, але все одно повинні бути якісь люди, які і всередині розуміють, як це все працює, і що це повинно бути. Вони повинні розуміти внутрішність продукту і повинні мати можливість локалізувати проблему. Вони повинні бути залучені в команду вашої компанії, просто тому що найчастіше, за законом підлості, аварії відбуваються вночі, і в якій би тайм-зоні би ви не були, коли людина прокидається від дзвінка керівника або партнера, або від смс про аварії, він повинен не забити, просто поклавши трубку, а зрозуміти, що відбувається біда, і потрібна його допомога.

Вони повинні володіти приголомшливою стресостійкістю, тому що іноді, особливо на запуск проекту, такі смс приходять кожен день перші півроку. Найчастіше на старті це розробники з задатками адміна, які і знають, як працює код, і можуть поправити, і знають, як подконфигурить сервер, щоб воно запрацювало. І повинні бути екстраверти, тому що якщо ви з ними працюєте або вам потрібно з ними взаємодіяти, дуже неприємно чекати протягом 30 хвилин або години, поки людина розбереться, але він при цьому про це не говорить. Тобто ти кажеш: «Вася, як справи?». А Вася не відповідає. Краще, якщо хоч хтось в цій команді є екстравертний, який скаже: «Хлопців, от там так-так і так, ми робимо це все, і зараз все виправимо».



Все це не працює без організації. Так, ця команда є, але потрібно розуміти, що вся ця команда у процесі підтримки дуже часто працює в хаотичних умовах. Прийшла аварія, для якої раніше ніколи не було, цю аварію виправили. Обов'язково потрібно зрозуміти, як ця аварія трапилася, як її виправили, і як зробити так, щоб її більше не було. Якщо ми виправили аварію і не зрозуміли, як це виправили, ми фактично її не виправили і отримаємо ще одну таку ж. Якщо у нас трапився інцидент, який не був замониторен, ми повинні принципово розуміти, що сталася аварія, вона не була замониторена, значить перші кроки, які повинні бути зроблені — це моніторинг сервера, моніторинг програми, щоб такий аварії більше не було.

Такі команди дуже не люблять бюрократію на момент боротьби з проблемою, на момент вирішення проблем, але далі потрібно домагатися формалізації того, що було проведено, формалізації всіх цих процедур.



Як працювати на підтримку такої штуки на запуск проекту. На старті, це будуть просто СМС-ки ключовим людям і телефонні дзвінки людей, які не сплять і постійно дивляться, як це працює. Потім, це, можливо, чергування людей всередині команди, додаткових людей. Для старту підходить двоє через двоє за 12 годин. Але довго люди не протримаються, просто тому що ті, хто будуть працювати в нічну зміну, у них, цілком можливо, є дружини, діти, сім'ї. І коли вони відпрацюють з 8-ї вечора до 8-ї ранку (це я кажу з життєвого досвіду), в 10-11 ранку їх ці ж самі дружини, діти, сім'ї, друзі, почнуть дзвонити і казати: «Вася, підемо далі». І дуже важко в цей момент і спати, і розуміти, що в тебе просто життя не залишається.

З досвіду: у кожного з людей, які отримують алерти, повинні бути мінімум три телефону критичних людей для оповіщення, яким він повинен дзвонити і повідомляти про те, що проблема. Один телефон можуть не взяти, два телефони можуть не взяти, але я не пам'ятаю випадків, коли при трьох телефонних дзвінках не брали трубки.



Додаткові метрики, які можна дивитися по підтримці вже через довгий час. Це Alerts per hour, бо треба розуміти, що ситуація, коли у вас немає аварії на живому проекті — це досить рідкісна ситуація, завжди щось відбувається не те. А ось кількість інцидентів, яке відбувається в якийсь період — у годину, тиждень, місяць, залежно від масштабу — це теж показник, за яким можна стежити. Якщо у вас протягом останнього півроку було п'ять інцидентів в тиждень, а протягом останнього місяця у вас п'ять інцидентів на день, це означає, що щось відбувається не так, потрібно все одно це розслідувати.

Час, проведений на серверах. Можливо, у вас 20 серверів і на одному з них проводять значно більше часу, ніж на інших. Можливо, сама команда цього не бачить, можливо, ви цього не бачите, але на цих серверах щось є, з чим потрібно розібратися.

Штука, яку ми нещодавно зробили для себе, — ми стали записувати SSH-сесії. Це не для контролю, а для того, щоб в результаті аварій зрозуміти, в чому причина. Не згадувати, що я робив в паніці останні півгодини, намагаючись швидко здійснити хірургічну операцію, а просто подивитися знову, знайти те, що було зроблено, записати, сформулювати і зрозуміти.



Ще про роботу. Це більше з розряду жартів. Якщо кілька ключових людей летять на одному рейсі в літаку, сервери обов'язково впадуть. Потрібно стежити за тим, щоб з ключових людей хтось завжди залишався в доступі для серверів.

Люди, які отримують СМС. Ідеально, щоб у них було, як мінімум, два способи зв'язку. Тобто отримувати телефонні дзвінки, бути з ноутбуком і т. п. — як мінімум, два способи зв'язку при собі. Тому що стільниковий зв'язок працює не повсюдно, телефони губляться, телефон може впасти, дві сімки — вже більш надійний захист… Ідеально, якщо на цих же симках буде налаштований редирект на недоступність на іншу людину, який буде на це відповідати. І останнє — життя таких людей важка, любите і цінуєте.



Замість висновків.

  • Просто зробити проект і запустити — не працює. Тобто якщо ви вірите в те, що ви сплануєте архітектуру, підготуєте сам проект, підготуєте код, запуститесь, і все буде працювати — ні. Проект живий, він постійно змінюється. Людина, і той, не буває здоровий все життя, у нього з'являються хвороби, у нього з'являються якісь болячки.
  • Замониторить і більше ніколи не впаде — теж не працює. Моніторинг — це штука, яка буде оповіщати вас про те, що відбувається.
  • Зарезервувати і не перевірити — не працює.
  • Зарезервувати, замониторить, але не організувати службу підтримки — не працює. Нехай у вас прилітає дуже багато алертів, але якщо ніхто не знає, що з ними робити, не зрозуміло, що робити далі.


Контакти
» eapotapov
» eapotapov@itsumma.ru
» Facebook
» itsumma.ru
» Блог компанії Itsumma

Ця доповідь — розшифровка одного з кращих виступів на навчальній конференції розробників високонавантажених систем HighLoad++ Junior.

Також деякі з цих матеріалів використовуються нами в навчальному онлайн-курс по розробці високонавантажених систем HighLoad.Guide — це ланцюжок спеціально підібраних листів, статей, матеріалів, відео. Вже зараз у нашому підручнику понад 30 унікальних матеріалів. Підключайтеся!

Ну і головна новина — ми почали підготовку весняного фестивалю "Російські інтернет-технології", в який входить вісім конференцій, включаючи HighLoad++ Junior. Ми, звичайно, жадібні коммерсы, але зараз продаємо квитки за собівартістю — можна встигнути до підвищення цін
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.