⛏️ Раскопки, раскопки, раскопки! Позанимаемся археологией в легаси проектах вместе с руководителем разработки Т-Банка

🎙 Приглашаем на разговор о легаси-проектах — тех самых, где документация утеряна, а комментарии в коде начинаются со слов «это магия, не трогать»

🕚 25 октября 18:00
🗺 Оффлайн участие: Санк-Петербург, Кронверкский проспект, д.49, Университет ИТМО, Пространство Яндекса (ауд. 2101)
🌐 Онлайн трансляцию тоже обещают

🎫 Для регистрации на мероприятие необходимо заполнить форму

👋 До встречи в Питере!

@downtime_bar #события #SRE #DevOps #Архитектура

Всем привет!

🎙 К нам сейчас приходит много новых людей и что бы новеньким было проще ориентироваться, а стареньким лишний раз напомнить зачем мы тут сидим, расскажу, чего можно ожидать: нам чуть больше года и мы стремимся делиться своими знаниями выступая на конференциях и проводя вебинары — в основном это лекции по темам связанным с высокими нагрузками и стабильностью, но бывают и тематические интенсивы - от одного вечера до нескольких дней. Прошедшие и будущие мероприятия, а также анонсы конференций и митапов доступны по тегу #события

👩‍💻 Так же мы с Дарьей, нашим Chief Product Officer, пишем для вас статьи, основанные на опыте работы с реальными клиентами и ситуациями. Такие статьи доступны по тегу #полезныематериалы, а основные из них мы собрали в небольшой список по разделам:

🏭 Про SRE и отказоустойчивость
- Что такое SRE?
- Какие навыки нужны SRE инженеру?
- Шпаргалка SRE: SLO, SLI и SLA
- Шпаргалка SRE: Код фриз
- Шпаргалка SRE: Мониторинг и алертинг
- Шпаргалка SRE: Виды деплоев
- Шпаргалка SRE: Почему падает прод?
- Шпаргалка SRE: Chaos Engineering

📚 Лонгриды по SRE (дольше 30 секунд)
- Готовимся к катастрофе (DRP) часть I, часть II, часть III
- Оптимизация стоимости в IT
- Антипаттерны в DevOps и SRE
- Культура взаимодействия между DevOps и SRE
- IT: эффективность и хайп

🎥 Серия статей "Жизненный цикл IT-компаний"
- Введение в жизненный цикл IT компании этапы и вызовы для бизнеса

- Технические вызовы при росте IT компании:
- Первый этап: зарождение (Start Up)
- Второй этам: ранний рост (Early Growth)
- Третий этип: Масштабирование (Scaling)
- Четвертый этап: зрелость (Maturity) и упадок (Decline)

- Сценарии краха и трансформации IT компаний:
- Сценарий 1: Трансформация
- Сценарий 2: Поглощение крупной компанией
- Сценарий 3: Крах

👨‍💻 Статьи про инженерную культуру
- Зачем нужна инженерная культура
- Как на собесе понять, что в эту компанию тебе не надо
- Индикаторы упадка компании
- Можно ли в одиночку поменять культуру в компании

🪣 Базы данных
- Базовая настройка MySQL
- Настройка транзакционного лога InnoDB в #MySQL

💡 Искусственный Интеллект
- Когда ИИ заменит всех людей

⬇️ Книги и сказки
- Мониторинг и инцидент менеджмент
- Архитектура и высокие нагрузки
- Что почитать что бы стать DBA
- Философия DevOps (на английском)
- Сказка на ночь от Дарьи

То чем мы занимаемся подробно описано на нашем сайте: https://fournines.ru

Чего не стоит ждать? У нас точно нет серебряных пуль, которые решают любую проблему в любом проде за три наносекунды. Мы даже честно пытались быть в тренде и решили заняться аффирмациями, но не взлетело.

Наоборот, в плане инженерного подхода мы довольно душные типы и любые гипотезы стараемся проверять через ревью, мониторинг, нагрузочное тестирование и только имея на руках понятные результаты внедрять плавные изменения в инфровой архитектуре, архитектуре приложения и IT процессах компаний с которыми работаем.

Пишите, что лично Вам хотелось бы обсудить на наших вебинарах и о чем прочитать в статьях.

Добро пожаловать в Даунтайм Бар и Гриль! 👋

Про космическую погоду: риски солнечных вспышек

Вчера и сегодня произошли две вспышки высшего класса Х. Сам по себе Х-класс событие довольное редкое, а два подряд не было давненько, последние такого уровня наблюдались в октябре 2003 года и мае 2024 года. При вспышках, солнцем выбрасываются облака заряженных частиц, а скорость облаков плазмы даже в районе орбиты земли превышает 800 километров в секунду, чем это грозит?

С точки зрения здоровья комментировать не могу, а вот сбои техники вполне ожидаемы из-за токов, которые поток заряженных частиц индуцирует в проводниках.

Наиболее вероятный ожидаемый аффект на прод: сбои памяти, нарушение консистентности данных, ошибки приложений и привет пятисотые, давно не виделись

С другой стороны - красивые полярные сияния можно будет наблюдать далеко за полярным кругом

Подробнее о космической погоде в канале лаборатории солнечной астрономии https://news.1rj.ru/str/lpixras/1784

Что еще почитать?

🏭 Про SRE и отказоустойчивость
- Что такое SRE?
- Какие навыки нужны SRE инженеру?
- Шпаргалка SRE: SLO, SLI и SLA
- Шпаргалка SRE: Код фриз
- Шпаргалка SRE: Мониторинг и алертинг
- Шпаргалка SRE: Виды деплоев
- Шпаргалка SRE: Почему падает прод?
- Шпаргалка SRE: Chaos Engineering

👨‍💻 Статьи про инженерную культуру
- Зачем нужна инженерная культура
- Как на собесе понять, что в эту компанию тебе не надо
- Индикаторы упадка компании
- Можно ли в одиночку поменять культуру в компании

🎥 Серия статей "Жизненный цикл IT-компаний"
- Введение в жизненный цикл IT компании этапы и вызовы для бизнеса

- Технические вызовы при росте IT компании:
- Первый этап: зарождение (Start Up)
- Второй этам: ранний рост (Early Growth)
- Третий этип: Масштабирование (Scaling)
- Четвертый этап: зрелость (Maturity) и упадок (Decline)

@downtime_bar #и_о_погоде@downtime_bar

Материалы готовили ко встрече в Питере, теперь Дарья, спасибо ей большое, причесала в виде текста и теперь с радостью с вами делимся:

Легаси - великое и ужасное!

❓Что такое «легаси»? Это только старый код или и процессы/инфраструктура?

Чтобы начать разговор о легаси системах, хочется в целом понять с какого периода проект или его часть становится легаси и по каким конкретным параметрам мы можем отделить легаси от не легаси?

Например, 100.000 строк – это достаточная величина кода, чтобы он считался легаси? А этот если этот код написан за неделю? А если за год? Одним человеком или командой? А эти люди сейчас с нами?

Таким образом, в попытках выделить объективные характеристики для определения легаси мы сталкиваемся с набором субъективных оценок. Потому что для старожилы, который этот код писал, это будет родной и понятный компонент системы, а для новичка - великое и ужасное легаси.

С одной стороны, на практике термин легаси употребляется как наследие, которое как правило:
⚪️ Написал не ты
⚪️ Ты не знаешь, как работает
⚪️ Или не помнишь
⚪️ Любая большая система

Либо есть еще вариант употребления легаси в значении системы, изначально написанной для решения других задач и часто с использованием устаревших технологий
⚪️ Со старыми связями
⚪️ Со старыми зависимостями
⚪️ C переусложненной логикой

При этом легаси может быть твоей системой, которую ты сам и написал 5 лет назад и смотреть туда уже страшновато.

Часто «легаси» имеет негативную смысловую коннотацию. Хотя это не совсем справедливо, потому что на практике встречаются очень качественные легаси системы, которые выступают надежной базой для проекта и позволяют ему расти стабильно на протяжении многих лет жизни бизнеса.

Легаси имеет несколько видов – главное разделение происходит на уровне софта и железа:

Софт
⚪️ Старый код
⚪️ Древние библиотеки
⚪️ Устаревшие компиляторы
⚪️ Вышедший из моды язык программирования
⚪️ Неподдерживаемые версии операционных систем, пакетов и драйверов

Железо
⚪️ Старые карты и компоненты: сеть, диски, процессоры
⚪️ Архитектуры
⚪️ Платформы (x86, spark, etc)

Архивные системы, когда железо не поддерживается и не выпускается, софт заброшен и не обновляется, становятся рисками эксплуатации и в конечном счете бизнеса.

При этом в нашем мире хайпа, что-то считается легаси уже через неделю, что-то через год-два после выхода, что-то через 3-5 лет, а что-то, не смотря на скепсис и сомнения, успешно работает десятками лет исправно принося деньги бизнесу.

Попытаемся сформулировать определение:

Легаси является эмпирической и субъективной оценкой программно-аппаратных комплексов, не является рациональной и не может использоваться в качестве аргумента при принятии технических и бизнес-решений

Что это значит? Увы, но позиция «это легаси во всем виновато» или «да это же древнее зло, там все надо срочно переписывать» скорее эмоциональная, чем валидная. В каждом конкретном случае необходимо разбираться, декомпозируя компоненты системы в поисках решений для оптимизации работы проблемных точек.

Продолжение:
- Легаси и костыли
- Когда пора перезжать и кто такие хранители легаси


#полезныематериалы @downtime_bar

Продолжение серии постов про легаси. Начало здесь: Что такое легаси?

Легаси и костыли

❓Можно ли получить полезные навыки работая с легаси?

Все счастливые системы похожи друг на друга, каждая система несчастлива из-за своего легаси.

На самом деле каждая легаси система открывает свой новый удивительный мир неочевидных зависимостей и причинно-следственных связей. Работая с "чужими" системами, специалист может получить набор крайне полезных навыков траблшутинга, реверс-инженеринга и эмоционального самоконтроля.

Глобально есть два варианта работы с наследием, оставленным прародителями – реактивная и проактивная работа.

Реактивная работа

Любой инцидент в незнакомой системе – это всегда приключение.

Иногда захватывающее и адреналиновое, как прыжок с парашютом, а иногда длинное и изматывающее, как затянувшаяся поездка на американских горках, где знаешь каждый поворот наизусть. Но в случае инцидентов нужно быть внимательным – в любой момент знакомый маршрут на рельсах может внезапно оборваться и за следующим поворотом уже может потребоваться парашют.

Какие полезные навыки реактивной работы можно получить работая на инцидентах с легаси системами?
⚪️ Траблшутинг
⚪️ Умение пользоваться инструментами мониторинга и диагностики
⚪️ Осознать, что такое reverse-engineering
⚪️ Пример? У вас падает любой прод - найдите причину и почините!
⚪️ Научиться анализу чужого кода и архитектуры
⚪️ Выявлять неочевидные зависимости в сложной системе
⚪️ Увидеть, как делать точно не стоит
⚪️ Посмотреть на полезные и красивые решения, которые можно забрать в свою копилку идей
⚪️ Получить навык быстрого поиска эффективных решений в заданных условиях

Проактивная работа
Проактивная работа при работе со старыми системами натыкается на свои особенности для команд эксплуатации и разработки.

Для Разработки это:
Увеличение времени на разработку за счет:
⚪️ Неочевидного кода и странных решений
⚪️ Подходов, которые были "лучшими практиками" 10 лет назад
⚪️ Старых версий языков и библиотек, ограничивающих функциональность
⚪️ Да это же просто Perl!

Для Эксплуатации это:
Возможность изучить проблематику и заняться такими проблемами как:
⚪️ Старые версии OS
⚪️ Версии библиотек, которые не найти под современные системы
⚪️ Сборки, давно исправленных баги которых являются несущими конструкциями прода
⚪️ Отсутствие совместимости с новыми инструментами
⚪️ Затаскивание в кубер кода, написанного до изобретения CI/CD

НО! Работа с чужим легаси помогает приобрести неоценимый опыт раскопок реальных систем и оптимизации работы кода. Правда вы уже никогда не будете прежним, но такова цена этих знаний.

И конечно же в любом легаси живут костыли!

❓Все мы знаем что костыли - плохо. Бывают ли ситуации когда без них никак не обойтись?

Костыли – часть той силы, что вечно хочет добра и вечно совершает зло. В практике часто бывают ситуации, когда костыль является необходимой мерой. В частности:
⚪️ Во время инцидента за минуту снимаем аффект на пользователей воткнув костыль, потом месяц его выпиливаем
⚪️ Выкатываем нужную бизнесу, но кривую фичу прямо здесь и сейчас, но растим технический долг
⚪️ Подпираем костылем уже существующий костыль, что бы прод не рухнул. Получаем костыль второго порядка и шаткий прод. Опасная практика.

Чтобы не запинаться за костыли необходимо вовремя разбираться с техническим долгом и очень стараться не делать из костылей несущие конструкции, используя их по назначению – подпер прод, восстановил работу, отбросил костыли и пошел дальше.

Продолжение: Когда пора перезжать и кто такие хранители легаси

#полезныематериалы @downtime_bar

Переезды и хранители легаси

💡Это продолжение серии постов. Начало здесь: Что такое легаси?

❓Как понять, что уже стоит переезжать на новую инфраструктуру и как доказать необходимость?

Самый главный объективный маркер необходимости переезда на новую инфраструктуру – стоимость. Золотое правило:

в случае, если эксплуатация старой инфраструктуры стоит больше, чем эксплуатация новой плюс стоимость переезда, то переезд необходим.

Но важно понимать из чего строится стоимость, которую придется высчитывать:

Стоимость:
💲Разработки
💲Эксплуатации
💲Найма

Высчитываем риски (вероятность повышения расходов):
💲Безопасности
💲Доступности запчастей


❓Кто такие «хранители легаси»? Признаки «хранителей легаси» и что делать если вы их встретили в своей компании?

Признаки хранителей легаси:
⚪️ Авторы, соавторы и свидетели легаси
⚪️ Долго работают в компании
⚪️ Не хотят переходить на новые технологии/железо/софт
⚪️ Делают как привыкли (нет желания, необходимости, сил выходить из зоны комфорта)

Почему люди не переходят по щелчку на новые технологии, языки, библиотеки и т.п.?

Дело в том, что переезд в любую новую среду делает неактуальными некоторые навыки, умения и наработки, что немедленно сказывается на скорости и качестве выходящих из-под рук хранителя легаси заклинания. И сколько это будет продолжаться, и будет ли в конечном счете новая технология так же эффективна, как текущая - может быть большим вопросом.

Если вы когда-нибудь переезжали из города в город или между районами большого города - вы понимаете о чем речь. Поэтому значительная часть людей с наработанным опытом будет до последнего держаться за свои знания и умения в поиске их применения, даже если они уже давно не валидны.

При попадании в команду с хранителем легаси, самый важный совет – коммуникация. Необходимо попробовать найти с ним общий язык. Если вам повезет, то хранитель выберет вас для передачи знаний и опыта. «А как понять, что он меня выбрал? Он захочет тебя убить.»

Но если серьезно, то общий язык с опытными членами команды – это очень важный аспект, потому что так у вас появляется возможность перенимать знания, продвигать собственные идеи и работать в более комфортных условиях.

Окончание цикла читайте здесь

#полезныематериалы @downtime_bar

💡Эта статья - окончание серии постов про легаси. Если не читали, начните здесь: Что такое легаси?

Старое или новое?

❓Если бы к вам пришёл junior DevOps и у него был выбор: идти в современный «зелёный» проект или в старый легаси, чтобы вы ему посоветовали?

Ключевой совет для всех новичков:

Вам нужно искать хорошую команду, где вас будут учить, и вы будете расти

У всех проектов – больших и маленьких, старых и новых – есть свои преимущества и недостатки. Все проекты индивидуальны и постоянно меняются в зависимости от команд, количества и качества сотрудников, руководства, целей компании, экономической ситуации и многих других факторов. При выборе необходимо понимать, что потенциально может ожидать вас:


Новый проект
Плюсы
▫️Пространство для креатива - делай что хочешь, любая архитектура, любые технологии
▫️Может получиться прорывная архитектура, которая победит все архитектуры в мире

Минусы
▫️А может получиться архитектура, на которую даже костыли не получится повесить, и вся команда пойдет на холодок
▫️Бывает, что сроки не всегда предполагают возможность:
- Обучения
- Внедрения новых технологий
- Задача сразу провальная, просто вы об этом догадаетесь не сразу
▫️В компании может быть технический радар - список допущенных технологий
▫️Не факт, что люди рядом с тобой могут писать хорошо


Легаси-проект
Плюсы
▫️Можно подсмотреть инженерные решения как в инфраструктуре, так и в разработке
▫️Можно научиться траблшутить
▫️Можно научиться трансформировать проект

Минусы
▫️Существующие ограничения могут быть жесткими
▫️Скорее всего придется получать разряд костылятора
▫️Новые функции, возможно, придется вешать где-то сбоку
▫️Лет через пять вы покроетесь мхом и уже вас будут называть хранителем легаси

Дисклеймер! Новизна ничего не гарантирует. Можно писать новый проект на перле и на любом языке программирования можно писать, как на фортране. Старина так же ничего не гарантирует. Старое не значит плохое, новое не значит хорошее. Так и живем.


Быстрые инсайты по всему циклу статей:

▫️Больших систем без легаси не бывает
▫️Даже средних систем без легаси не бывает
▫️Если при работе в больших и средних компаниях вы все равно с легаси столкнетесь
▫️За легаси платят
▫️Все чему вы сейчас учитесь в какой-то момент, станет легаси
▫️Все новое - хорошо забытое старое: важно понимать откуда появились подходы и технологии, это может помочь в создании нового

Что еще почитать?

🎥 Серия статей "Жизненный цикл IT-компаний"
- Введение в жизненный цикл IT компании этапы и вызовы для бизнеса

- Технические вызовы при росте IT компании:
- Первый этап: зарождение (Start Up)
- Второй этам: ранний рост (Early Growth)
- Третий этип: Масштабирование (Scaling)
- Четвертый этап: зрелость (Maturity) и упадок (Decline)

👨‍💻 Статьи про инженерную культуру
- Зачем нужна инженерная культура
- Как на собесе понять, что в эту компанию тебе не надо
- Индикаторы упадка компании
- Можно ли в одиночку поменять культуру в компании

💡 Искусственный Интеллект
- Когда ИИ заменит всех людей

#полезныематериалы @downtime_bar

Чеклист к черной пятнице
Для CTO, CIO, DevOps, SRE и эксплуатации в целом

Всем привет!

Если Вы продаете товары или оказываете какие-то услуги, то скорее всего ваши маркетологи уже придумали чем заманить пользователей в черную пятницу. Как пережить всплеск нагрузок без даунтайма я Вам без понимания вашего прода не расскажу, а вот ключевые моменты в виде чеклиста подсветить - это пожалуйста:

Если что-то пойдет не так - Вы должны узнать об этом сразу
- У Вас есть мониторинг инфраструктурного, сервисного и бизнес уровней
- Если какой-то сервер/кластер/нода будут перегружены и начнут отвечать медленно Вы увидите этот факт в мониторинге
- Есть метрика количества ошибок, которые получают пользователи
- Есть метрика, показывающая количество успешных заказов/транзакций/оплат или других ключевых бизнес действий
- На основных метриках стоят алерты, поэтому если что-то пойдет не так, Вы узнаете о проблемах от системы мониторинга, а не от своих пользователей

Вы знаете запас своего прода по нагрузке
- Вы обсудили с маркетингом ожидания по увеличению нагрузки (+10%, +50%, х2, х3, х10) к обычному дневному трафику
- Пересчитали общий ожидаемый трафик к пиковому
- Сделали нагрузочное тестирование, которое показало, что прод переварит рассчитанный пиковый трафик с достаточным запасом
- В случае если трафика придет больше (а это всегда приятная проблема) и система не будет его выдерживать, есть пошаговый план отсечения пользователей для того, что бы какая-то из часть смогла воспользоваться системой, этот план проверен и согласован с бизнесом

Дополнительные глаза и руки
- Все люди в командах эксплуатации и разработки осведомлены о днях и времени, когда на проде ожидаются повышенные нагрузки
- Вы поставили дополнительных дежурных на дни пикового трафика
- Ключевые сотрудники не в отпуске и предупреждены о необходимости в вышеуказанные даты иметь возможность быстро подключиться для решения экстренных задач, даже если это выходной день
- Команда знает точный адрес звонка, где нужно будет собраться, если что-то пойдет не так

Если что-то пойдет не так
- Дежурные первой линии поддержки или команды мониторинга способны быстро (в течении пары минут) определить степень влияния инцидента на конечных пользователей
- У дежурных есть понятный лист эскалации, в котором прописан план эскалации в зависимости от степени влияния на пользователей, а также телефоны ответственных по каждому компоненту
- За каждым компонентом на время повышения трафика закреплен ответственный человек, который выполнит его глубокую проверку в случае общего сбоя
- Есть архитектурная карта компонентов и их зависимостей, в карте прописаны внешние сервисы, которые используются системой, даже если они не участвуют в обработке пользовательского трафика. Людям на инциденте не нужно будет натужно вспоминать какие компоненты на что влияют
- Что бы уменьшить вероятность инцидентов на время пиковых нагрузов вы ввели код и инфра фриз

Быстрая памятка
🗓 Готовимся заранее, а не за неделю
📈 Планируем нагрузку с бизнесом и маркетингом
🥶 На время нагрузки объявляем фриз
🖥 Во время нагрузки сидим online, мониторим, готовые быстро поднимать упавшее

Пересылайте чеклист коллегам, пишите нам в @downtime_bar о том чего в нем не хватает и как лично Вы готовите прод к черной пятнице. Всем спокойных дежурств и хороших выходных!

@downtime_bar #полезныематериалы