Site Reliability Олег

В своём канале Женя Потапов, основатель компании ITSumma вспомнил забавную историю про додо, хайлоад и тесный мир. Ну и я там тоже немного есть.

Кстати, это запись с прошлогоднего DevOops. В этом году он будет совсем скоро, 16-17 сентября в Питере. Как участник программного комитета, готов поделиться личным промокодом, если надо - пиши в лс @jmistx.

#видеозаписи Порой к эффективному подходу приходишь ценой набитых шишек. Зато есть о чём рассказать на конференции, чтобы другие набили чуть поменьше! В рубрике #ПятничныйДеплой — доклад о «забеге по граблям на долгие дистанции». YouTube | VK Видео Скачать перезентацию с сайта DevOops

Как мы сделали процессы вокруг инцидент-менеджмента в Додо. Давно хотел рассказать о процессах вокруг обеспечения надёжности, которые мы построили с Серёгой Бухаровым и Виталиком Уваровым. Это должна была быть поучительная история длинной в три года о том как напрягать и расслаблять бюрократию, заменять её техникой и правильно чертить границы ответственности. Руки у меня постоянно не доходили, а вот у Серёги дошли. Я постоял рядом в роли эксперта, помог триста раз прогнать и переделать выступление. Для меня это трогательный слепок истории и один из важных итогов двухлетней работы лидером инфраструктуры в Додо. Стоит посмотреть, если интересно увидеть внутрянку SRE процессов в IT на 300 человек, примерно 50 сервисов (не микро-), где 5 минут простоя продукта обходятся в миллион рублей.

My Philosophy on Alerting (2/2) #monitoring Я утверждаю, надо со всей силы бороться чтобы типов алертов было мало. Чем больше самописных алертов, тем больше из них срабатывает, и часть из них срабатывают не по делу. Через какое-то время у дежурного случается alert fatigue. Alert fatigue - усталость от сигналов тревоги - для маленьких команд поддержки проблема худшая, чем инцидент. Если нести дежурство физически невозможно качественно – каждый его несёт как может. Обратная связь от пользователей снова становится основным каналом возбуждения инцидента. Как сделать так, чтобы алертов было мало? Согласно статье, алертить надо не на причины (недоступность базы, ООМы, закончившиеся коннекшны), а на симптомы - существенно выросший latency, 5xx и 4xx, неспособность пользователя сделать определённое действие. В додо почти все инциденты начинались с единственного алерта на 5xx. На встрече мы вспомнили два качества хорошего алерта: actionable и real. Алерт должен быть Actionable. У каждого алерта должен быть ранбук, без него алерт бесполезен для большей части команды. Что может быть прекраснее ситуации, когда вечером пятницы тебе пришёл алерт на CPU, и ты понятия не имеешь что с ним делать. Снять нагрузку с приложения? Может надо посмотреть топ лог? А это вообще плохо? А какие пользователи страдают и насколько сильно? Может просто подождать и рассосётся? При этом писать ранбуки непростая, часто неблагодарная работа. Ещё сложнее их поддерживать в актуальном состоянии. Чем больше алертов - тем больше такой работы. Желающие повыгорать поднимите руки. Алерт должен быть Real. По алерту должно быть понятно - кто и как сильно страдает. Никто? Не надо чинить то, что не сломано. Если этого не видит и не увидит пользователь - значит это не инцидент. Много коннекшнов может говорить о проблемах, а может говорить о том что вы используете ресурсы. Также как и высокая утилизация CPU может говорить о кратковременном пике или о системной проблеме. Если это прямо сейчас не аффектит пользователей - это не повод в авральном режиме что-то чинить прямо сейчас. Хотя мне иногда самому нравится устроить аврал на ровном месте, такие вещи можно планировать и разбирать раз в неделю по метрикам. Какие алерты мне нравятся - алерты на симптомы: latency, 5xx, 4xx - алерты на пользовательские сценарии: сейчас мы запускаем подмножество автотестов прямо на проде раз в 5 минут, если один из них не прошёл у нас - значит он не работает и у пользователя. Заводим моторы. - алерты на SLO: можно было бы оставить только их - обычно это уже признак зрелой команды и сервиса. Пока что видел хорошо сделанные только в Контуре на сервисах с хорошо формализованными пользовательскими сценариями и достаточно высоким RPS для набора статистики. - blackbox мониторинг - если внешний пробер не достучался до нас, значит из той локации мы недоступны. Пока сидели-обсуждали нашли пару важных исключений, про которые я понял, что не готов спорить и на них действительно стоит держать отдельные алерты. Алерты на сатурацию в системах, где полная сатурация означает отказ: место на диске; троттлинг CPU; переполнившаяся очередь; кэш, который обещает заполнится в течение часа. На что не алертить? Из самого очевидного - не надо звонить на отказ компонента. Это полезно подсветить на мониторинге любым способом - но триггерится надо не на него, а на проблемы пользователей. Очевидный дисклеймер: всё зависит от продукта, надо думать головой. От наших сервисов не зависит жизнь пользователя. Мы обсуждали типичный вебчик с кронами, очередями, воркерами, базой и кешем. Если ваш сервис - это сетевая инфраструктура, или S3 или база данных, то очевидно что у вас типичные пользовательские сценарии другие.

My Philosophy on Alerting (1/2) #bookmarks #monitoring Сегодня с новой командой при разборе инцидента, всплыло предложение “а давайте повесим алерт и в следующий раз быстрее заметим”. Это стало поводом зарубиться, что должно быть предметом алерта: стоит ли алертить, например, на ООМ или заканчивающееся место, на 100% CPU, на отсутствие сетевой связанности. Это заставило вспомнить статью, которую я поместил в заголовок поста. Её написал один из бывших инженеров google и пять лет назад она сформировала моё отношение к нотификациям. Лучше читать в оригинале, дальше будет моё мнение и пятилетний опыт дежурств в додо. - My Philosophy on Alerting: https://docs.google.com/document/d/199PqyG3UsyXlwieHaqbGiWVa8eMWi8zzAn0YfcApr8Q/edit?tab=t.0 - Hacker News Discussion https://news.ycombinator.com/item?id=8450147 - Alerts on SLO https://sre.google/workbook/alerting-on-slos/

Закладки SRE #music #bookmarks Вот тебе (и мне) музыки для программирования. Мне особенно нравится плейлист 01: Datasette. http://musicforprogramming.net

Закладки SRE #VCS #development #git #bookmarks Если вы прошли learngitbranching из прошлого поста про git, вам уже ничего не страшно и пора замыкать круг осознания. Для этого вы берёте официальную книжку по гиту (можно даже на русском) https://git-scm.com/book/ru/v2 и читаете. Предлагаю читать в случайном порядке по принципу "ой какой интересный заголовок", с обязательным потреблением главы "Git изнутри". А потом и от корки до корки можно.

Закладки SRE #VCS #development #git #bookmarks Три года назад мы всей компанией переезжали с mercurial на git. Всё надо было сделать за два дня, при этом сохранить схему веток и дать нескольким десяткам разработчиков набор правил, следуя которым они точно ничего не сломают и не потеряют свой код. До этого момента весь мой опыт сводился к мышекликанью в SourceTree и паре PR на github. А тут надо было срочно разобраться самому и объяснить другим. Вот штука, которая уложила в голове всё за пару вечеров. Интерактивная, браузерная, весёлая. https://learngitbranching.js.org/

Продолжение про слепую печать. Цифры и советы #лонгрид #development Когда Олеся (наш IT-редактор и мой старый хороший друг) прочитала первую часть про слепой десятипальцевый, она решила позадавать мне вопросов. Так появились "Цифры и советы". Цифры – специфичные для слепой печати, а советы – универсальные, точно так же я осваиваю любой другой навык. Цифры – Почему ты выбрал этот тренажер? Много пробовал? – Немного. 4 или 5. В том числе и заточенные под программистов. typingclub.com понравился качеством обратной связи: каждый косячный символ подсвечивается, статистика по пальцам, клавишам и вообще. Осмысленные английский текст. Обучение разбавлено мини-играми. У меня есть коллега, которому понравился https://keykey.ninja/ для мака. – Сколько в день тренил? – По-началу – много. 6 часов в неделю. То есть где-то по часу в день. Сейчас мне кажется, что я лишнего упарывался и можно было делать это спокойней. – В какой момент перестал смотреть на клавиатуру в обычной работе? – Пробовал не смотреть с самого начала. Особенно если происходило что-то не срочное. У меня есть пароль на 24 символа, первые разы написать без запинки было сложно. Хард стоп поставил себе, когда смог стабильно выбивать 35 wpm на тренажере. После этого запретил себе смотреть на клавиши в работе. – Сколько всего потратил? – Сейчас посмотрел, 40 часов в сумме. Но это ещё не все задания, осталось чуть меньше половины. На самом последнем – тренажёр требует 75 WPM. Советы Советы у меня такие: экспериментируйте и отдыхайте. Экспериментируйте Так получилось, что, кроме слепой печати, за последний год я осваивал много вещей, которые нужно было выводить в мышечную память: уницикл (одноколёсный велосипед), сёрф, начал трогать фортепиано (слегка). Когда-то давно выступал с жонглированием. И для всех них у меня общий подход. Попробую его описать. Ваша задача выполнить элемент в максимальном числе вариаций. В жонглировании – начать с другой руки или сместить внимание с поимки шара, на правильность броска. На фортепиано – начать играть фразу с середины или тренироваться без звука. На уницикле – следить правильностью позы, а не за равновесием. Даже ценой падения. Тренажёр говорит цель: 100% точность и определённая скорость. Но не говорит как её добиться. Вот ты сделал упражнение. У тебя 3 звезды из 5-ти. Первое желание – повторить. Вдруг будет больше? Будет. Или не будет. Я так по 15 минут повторял с переменным успехом. Выход – сделать так, чтобы при повторении работала голова. Как? ⁃ чередовать алгоритм работы с ошибками ⁃ ставить промежуточные цели, связанные с точностью, а не со скоростью ⁃ иногда нарочно писать медленнее, чем хочется ⁃ концентрироваться на ритме печатие, а не на аккуратности ⁃ менять места, где вы тренируетесь По очереди использую три алгоритма действий в случае ошибок: ⁃ продолжать без исправления ⁃ исправлять, как если бы это был обычный текст, только сами опечатки ⁃ стирать последние 6 символов от последней ошибки и перепечатывать, пока не сделаю без ошибок Зачем? ⁃ каждый раз приходится думать немного по-другому, поэтому внимание не притупляется Плохой алгоритм: “в случае ошибки начинать заново”. Так ты будешь тренировать всё время одно и то же, очень медленно продвигаясь вперёд. Иногда ставлю цели, связанные с аккуратностью Постараться не ошибиться ни разу в написании: - определённой буквы во всём тексте - конкретного набора слов, в которых обычно совершаешь ошибки - всех первых букв во всех словах - всех последний букв во всех словах - всех знаков препинания - ... Отдыхайте При монотонном повторении, организм переходит в зомби-мод. Сам этого не замечаешь. Можно ставить будильник на 10-15 минут. И делать перерыв, даже если думаешь, что у тебя и так всё хорошо. Как-то в предисловии к книжке по Objective-C (на котором я не программирую) прочитал фразу, которую стоит помнить в процессе любого обучения. Ей я и хочу закончить. “Это не вы тупой, это Objective-C сложный. По возможности спите по 10 часов в сутки.”

Закладки SRE #development #VCS #git #svn Сегодня зайду с классики. Системы контроля версий. Хенрик Книберг вещает про модели ветвления. Если дождливым вечером вы захотите переизобрести git flow – тут есть все необходимые знания. https://www.infoq.com/articles/agile-version-control

Разогревающие задачки для воркшопа по дизайну систем. Аббривеатура NALSD расшифровывется Non Abstract Large System Design. Давайте поговорим про этот “Non Abstract”. Если дизайн “не абстрактный”, то какой он? Конкретный. То есть, мы попытаемся посчитать сколько нам нужно серверов, какой ёмкости у нас должны быть диски и сколько памяти надо для приложения. Прикидываем, где в нашей системе бутылочные горлышки и какие можно придумать стратегии, для их устранения. При этом оперируем конкретными числами. Этот процесс называется “Back of the envelope calculations”. По-русски можно сказать “подсчёт на салфетке”. Обычно, для таких вычислений нам не хватает данных. При проектировании, мы ещё не знаем сколько будет запросов в секунду, сколько в точности стоит сервер и сколько человек нужно на поддержку выбранного решения. Но мы попытаемся оценить эти значения. На собеседованиях иногда спрашивают задачки вроде “сколько канализационных люков в Лондоне?”. Они как раз пытаются проверить вашу способность оценивать. Задача На разогреве, перед воркшопом, я даю задачку: “Посчитайте объём обычного среднего яблока”. Попробуйте решить её максимально быстро, не читая дальше. Решение #0 Большая часть участников тщетно пытается вспомнить формулу объёма шара. Так сказать, аппроксимировать яблоко шаром. Обычно, это путь в никуда. Даже если вспомните, пользоваться ей не особо удобно без калькулятора. Я предложу вам несколько решений, которые приведут к решению быстрее. Два их трёх предложили участники воркшопа. Решение #1 Аппроксимировать яблоко кубом. Объём куба проще искать, чем объём шара. Оценить ребро куба и умножить три раза. Решение #2 Вспомнить сколько весит яблоко (или сколько в килограмме яблок) и предположить, что оно состоит целиком из воды. Решение #3 Сравнить яблоко с чем-нибудь. Оно поместится в моём стакане? Какого объёма мой стакан? Резюме Во всех 4х случаях ответы получаются примерно одинаковые. Но одно решение даст тебе ответ за секунду, а второе – задержит на 2 минуты. Для быстрых вычислений, выбирайте те решения, которые дадут вам ответ быстро, даже если точность пострадает. Более того, в самом гугле для таких вычислений предлагают считать что в сутках 25 часов, а в году 300 или 400 дней. Не правда ли кощунство?

Закладки SRE #nalsd Если вы решили упороться и пойти собеседоваться, скажем, в Яндекс, или провести романтический вечер с девушкой, вот собранный сообществом букварь проектировщика. С задачами и ответами. Если бы меня спросили инопланетяне: "Олег, дай одну ссылку, так чтобы мы проектировать научились", я бы дал её. https://github.com/donnemartin/system-design-primer

Закладки SRE #nalsd Прошёл DotNet митап. Про NALSD рассказал и обещал ссылки. В интернете именно про NALSD мало (видимо, Гугл не вложился в маркетинг). Но есть много смежных историй, на которых можно тренироваться. Итак. Точка входа. Глава про NALSD из SRE Workbook 2018го года. Тут рассказывают о методе и применяют его к проектированию google AdWords: https://landing.google.com/sre/workbook/chapters/non-abstract-design/ Если вы экстрасенс и умеете восстанавливать выступление по слайдам, то вот слайды, где ребята из гугла рассказывают основы проектирования распределённых систем. Дают задачку на проектирование системы логов и показывают, как её можно решать. https://www.usenix.org/sites/default/files/conference/protected-files/srecon18americas_slides_virji.pdf То же самое, но для сервиса с фотографиями. Вдруг вам придётся проектировать flickr? Но тут ещё видос в комплекте с разбором решения. Держите ухо востро. Их решение не удовлетворяет требованиям к надёжности, которые они сами себе ставят. https://www.youtube.com/watch?v=ohtqI3AHR0k https://www.usenix.org/sites/default/files/conference/protected-files/srecon18emea_slides_geisberger.pdf Я в презентации использовал "Волшебный лоадбалансер" как доступный элемент инфраструктуры. Вот тут про настоящие написано верхнеуровнево (если продерётесь через баннеры, соглашение использовать куки и прочие необходимости современного интернета). https://avinetworks.com/what-is-load-balancing/ Вообще весело читать заметки людей, которые съели пуд г̶о̶в̶ соли на распределённых системах. Если NALSD не зацепил, почитайте хотя бы это. https://www.somethingsimilar.com/2013/01/14/notes-on-distributed-systems-for-young-bloods/ http://www.rgoarchitects.com/Files/fallacies.pdf И конечно "Числа, которые должен знать каждый программист". Теперь вы знаете нафига их знать. https://gist.github.com/tomhostyn/42344463f9505e8264a5c55e3655fe03

Site Reliability Олег pinned «Привет! Я Олег и я Site Reliability Engineer в Додо Пицце. Сюда скидываю интересные (одному мне) ссылки про надёжность, математику и программирование. Ещё графоманю на рабочие темы, рисую картинки, анонсю анонсы, истории рассказываю.»

Привет! Я Олег и я Site Reliability Engineer в Додо Пицце. Сюда скидываю интересные (одному мне) ссылки про надёжность, математику и программирование. Ещё графоманю на рабочие темы, рисую картинки, анонсю анонсы, истории рассказываю.

Channel photo updated

Закладки SRE #nalsd Бриллиантовая статья от mail.ru про то, как экономить в go на памяти для спящих подключений. Главное в статье – не go, а рассуждения автора. https://habr.com/en/company/mailru/blog/331784/

Закладки SRE #concurrency #database На тот случай, если до сих пор не знаешь, чем отличается optimisic concurrency от pessimistic, вот коротенький обзор. Обязательно знать каждому, кто делает многопользовательски приложения, которое работают с данными. http://www.agiledata.org/essays/concurrencyControl.html В зависимости от задачи, в реальном приложении необходимо решить как делать concurrency control: - механизмами Базы Данных? Тогда обязательно понимать как работают уровни изоляции транзакций. - механизмами вашего ОРМ? Тогда надо понимать, как оно реализовано под капотом. - писать самостоятельно? Часто – неплохой вариант. Такой простой concurrency control помогает справится только с проблемами в рамках одного инстанса базы. Если история про распределённую систему, то всё становится на порядки сложнее. Об этом как-нибудь потом.

Закладки SRE #nalsd Про NALSD в интернетах очень мало написано. Но вот офигенный пример от русскоговорящего инженера из Google. Он приводит алгоритм проектирования системы на примере сети городских библиотек. https://habr.com/en/company/google/blog/435898/