Forwarded from Синицын, бл🤬
Друзья, я опять с вакансией
Мне нужен руководитель команды Operations. Не, даже не так. Мне нужен охереть какой крутой лид в команду опсов.
Я отдаю себе отчет, что человека, которого я ищу, на свободном рынке просто нет, такие люди не выходят в поиск, они меняют работу за полчаса, просто списавшись со знакомыми руководителями
Но вдруг, вдруг... Вдруг кто-то из них читает мой канал и ищет работу, я верю в удачу, мазафака! Я — ваш знакомый руководитель, спишитесь со мной, а? 🥹
Итак, нужно возглавить команду очень крутых сеньоров-админов. Это не девопсы, это, скорее, ближе к SRE, прям очень ближе. Парни — огонь! Правда очень и очень крутые
Тому, кто таки захочет за это взяться, обязательно нужна хорошая экспертиза в linux, сетях, высоконагруженных системах, хороший технический кругозор. В идеале, нужна хорошая экспертиза по kafka, etcd и vault. Но это в идеале. Если у вас такой нет, но вы понимаете, что такое bigtech, реальный хайлоад и сложные процессы, то приходите
Я ищу в большей степени техлида. Мне нужен человек с экспертизой и со своим мнением, который сможет его обосновать и защитить, если понадобится.
Менеджерских задач также будет некоторое количество, бэклогом, стратегией и командой все-таки тоже надо управлять.
Для понимания немного сухих фактов:
🔘 У нас самый большой и нагруженный сетап кафки в РФ и один из самых больших в мире
🔘 В пиках в высокий сезон мы видели цифры в 17М (семнадцать миллионов) сообщений в кафке в секунду. Кафка выдержала. Надо научить ее держать в два раза больше.
🟡 Несколько раз в год мы отключаем один из ЦОДов на живом трафике и все должно работать как и работало. Мы настолько верим в себя, что можем позволить себе такие учения.
🔘 Мы — платформенная команда и наши клиенты — это продуктовые разработчики и другие платформенные команды, это очень дотошные и требовательные заказчики
🔘 Мы сами придумываем себе задачи и строим стратегию развития и делаем это хорошо
🟢 У нас форкнутые версии волта, кафки и etcd, мы дописываем их сами. Ванильные уже не выживают на наших нагрузках
🟣 В нашем проде более 5 000 микросервисов и больше 200 технических команд. Они все очень много используют наши сервисы
Немного про нашу команду я писал вот в этом посте. Лида команды разработки я успешно нашел, спасибо, что спросили😊
Вакансия на Ozon.Job: https://job.ozon.ru/vacancy/rukovoditel-gruppi-operations-message-bus-paas-112995867/
Еще раз повторюсь: это прям челлендж-челлендж. Работы много, работа сложная, работа ответственная. Мне не подойдут вонаби-менеджеры, которые умеют хорошо говорить, но которые не делали ничего руками и не в состоянии пройти интервью по system design. Мне не подойдут люди, которые годик управляли маленькой командой в маленьком стартапе, у нас реально "большая вода", они просто не вывезут. Мне не подойдут люди, которые про хайлоад слышали только на "Хайлоаде". Только ветераны войн за аптайм, с горячим сердцем и холодной головой.
Если чувствуете в себе силы пособеседоваться, то пишите мне на asinitsyns@ozon.ru
Ну или перешлите вакансию знакомому лиду
〰️〰️〰️〰️〰️〰️〰️
🗞 @boombah_in_da_house
Мне нужен руководитель команды Operations. Не, даже не так. Мне нужен охереть какой крутой лид в команду опсов.
Я отдаю себе отчет, что человека, которого я ищу, на свободном рынке просто нет, такие люди не выходят в поиск, они меняют работу за полчаса, просто списавшись со знакомыми руководителями
Но вдруг, вдруг... Вдруг кто-то из них читает мой канал и ищет работу, я верю в удачу, мазафака! Я — ваш знакомый руководитель, спишитесь со мной, а? 🥹
Итак, нужно возглавить команду очень крутых сеньоров-админов. Это не девопсы, это, скорее, ближе к SRE, прям очень ближе. Парни — огонь! Правда очень и очень крутые
Тому, кто таки захочет за это взяться, обязательно нужна хорошая экспертиза в linux, сетях, высоконагруженных системах, хороший технический кругозор. В идеале, нужна хорошая экспертиза по kafka, etcd и vault. Но это в идеале. Если у вас такой нет, но вы понимаете, что такое bigtech, реальный хайлоад и сложные процессы, то приходите
Я ищу в большей степени техлида. Мне нужен человек с экспертизой и со своим мнением, который сможет его обосновать и защитить, если понадобится.
Менеджерских задач также будет некоторое количество, бэклогом, стратегией и командой все-таки тоже надо управлять.
Для понимания немного сухих фактов:
Немного про нашу команду я писал вот в этом посте. Лида команды разработки я успешно нашел, спасибо, что спросили
Вакансия на Ozon.Job: https://job.ozon.ru/vacancy/rukovoditel-gruppi-operations-message-bus-paas-112995867/
Еще раз повторюсь: это прям челлендж-челлендж. Работы много, работа сложная, работа ответственная. Мне не подойдут вонаби-менеджеры, которые умеют хорошо говорить, но которые не делали ничего руками и не в состоянии пройти интервью по system design. Мне не подойдут люди, которые годик управляли маленькой командой в маленьком стартапе, у нас реально "большая вода", они просто не вывезут. Мне не подойдут люди, которые про хайлоад слышали только на "Хайлоаде". Только ветераны войн за аптайм, с горячим сердцем и холодной головой.
Если чувствуете в себе силы пособеседоваться, то пишите мне на asinitsyns@ozon.ru
Ну или перешлите вакансию знакомому лиду
〰️〰️〰️〰️〰️〰️〰️
🗞 @boombah_in_da_house
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4❤1
Strong Consistency: между производительностью и надежностью данных
Strong consistency — ключевой принцип в распределенных системах, гарантирующий, что все узлы видят одинаковые данные в любой момент времени. При любом обновлении изменения мгновенно становятся видимыми для всех последующих операций чтения.
Технически это достигается через линеаризуемость операций — все действия должны выполняться атомарно и по сути выстраиваться в единую временную линию. Синхронная репликация и двухфазный коммит гарантируют, что любое изменение будет применено ко всем репликам до того, как клиент получит подтверждение.
Жизненный пример — банковские транзакции. Когда система переводит деньги между счетами, критически важно, чтобы все узлы системы видели актуальное состояние баланса. Рассинхронизация даже на секунду может привести к дублированию списаний или потере транзакций.
На практике реализация strong consistency требует серьезных компромиссов. Задержки на синхронизацию увеличивают латентность, а при сетевых сбоях система может временно перестать принимать запросы на запись — цена за гарантию целостности данных.
Альтернативы вроде eventual consistency предлагают лучшую производительность и доступность, жертвуя строгими гарантиями согласованности. Выбор между ними определяется теоремой CAP: нельзя одновременно обеспечить консистентность, доступность и устойчивость к разделению сети.
К сожалению, универсального решения не существует. Критичные финансовые и медицинские системы выбирают strong consistency. Социальные сети и стриминговые сервисы предпочитают eventual consistency. Все зависит от требований конкретного проекта и цены потенциальной ошибки.
🏴☠️ @happy_devops
Strong consistency — ключевой принцип в распределенных системах, гарантирующий, что все узлы видят одинаковые данные в любой момент времени. При любом обновлении изменения мгновенно становятся видимыми для всех последующих операций чтения.
Технически это достигается через линеаризуемость операций — все действия должны выполняться атомарно и по сути выстраиваться в единую временную линию. Синхронная репликация и двухфазный коммит гарантируют, что любое изменение будет применено ко всем репликам до того, как клиент получит подтверждение.
Жизненный пример — банковские транзакции. Когда система переводит деньги между счетами, критически важно, чтобы все узлы системы видели актуальное состояние баланса. Рассинхронизация даже на секунду может привести к дублированию списаний или потере транзакций.
На практике реализация strong consistency требует серьезных компромиссов. Задержки на синхронизацию увеличивают латентность, а при сетевых сбоях система может временно перестать принимать запросы на запись — цена за гарантию целостности данных.
Альтернативы вроде eventual consistency предлагают лучшую производительность и доступность, жертвуя строгими гарантиями согласованности. Выбор между ними определяется теоремой CAP: нельзя одновременно обеспечить консистентность, доступность и устойчивость к разделению сети.
К сожалению, универсального решения не существует. Критичные финансовые и медицинские системы выбирают strong consistency. Социальные сети и стриминговые сервисы предпочитают eventual consistency. Все зависит от требований конкретного проекта и цены потенциальной ошибки.
🏴☠️ @happy_devops
👍4
Forwarded from DevOpsConf Channel
Гонка за новым функционалом не должна превращать систему в «хрупкого гиганта». SRE-практики помогают определить «точку невозврата» и выстроить процессы поддержки SLA. Если вы хотите научиться проектировать устойчивые системы и оберегать их от неожиданных падений, секция «Reliability Engineering» будет для вас незаменима.
Вторая часть докладов секции ⤵️, первая здесь
1) Blameless culture. Как правильно работать с инцидентами. Андрей Синицын (Ozon)
Принцип старой школы: «у любой проблемы есть имя и фамилия». Слышали? Может, сами практикуете или бывали такими именем и фамилией? Из доклада вы узнаете, почему культура без обвинений более эффективна, почему это не про всепрощение и расслабон и как запустить такой подход у себя.
2) Как жить, когда у тебя N тысяч алертов в секунду. Кирилл Борисов (VK)
Доклад про цикл жизни систем алертинга — от самого зарождения, когда только нащупываются подходы, до уже зрелой системы со своим собственным флоу.
3) Непрерывность как вид искусства. И почему доступности в 3,5 девятки вам достаточно. Глеб Тильтиков (МТС Диджитал)
Глеб расскажет о реальном применении SRE-практик, на личном примере рассмотрит оправданное добавление ещё одной девятки и когда от заботы о «pets» нужно переходить к «cattle».
🖐️ Ждём вас 7 и 8 апреля в Москве на DevOpsConf 2025.
✅ Программа конференции и билеты на сайте
Вторая часть докладов секции ⤵️, первая здесь
1) Blameless culture. Как правильно работать с инцидентами. Андрей Синицын (Ozon)
Принцип старой школы: «у любой проблемы есть имя и фамилия». Слышали? Может, сами практикуете или бывали такими именем и фамилией? Из доклада вы узнаете, почему культура без обвинений более эффективна, почему это не про всепрощение и расслабон и как запустить такой подход у себя.
2) Как жить, когда у тебя N тысяч алертов в секунду. Кирилл Борисов (VK)
Доклад про цикл жизни систем алертинга — от самого зарождения, когда только нащупываются подходы, до уже зрелой системы со своим собственным флоу.
3) Непрерывность как вид искусства. И почему доступности в 3,5 девятки вам достаточно. Глеб Тильтиков (МТС Диджитал)
Глеб расскажет о реальном применении SRE-практик, на личном примере рассмотрит оправданное добавление ещё одной девятки и когда от заботы о «pets» нужно переходить к «cattle».
🖐️ Ждём вас 7 и 8 апреля в Москве на DevOpsConf 2025.
✅ Программа конференции и билеты на сайте
🔥6❤2
Eventual Consistency: когда доступность важнее мгновенной согласованности
Eventual consistency — модель согласованности, ставшая фундаментом современных распределённых систем. Ключевая идея проста: система гарантирует, что при отсутствии новых обновлений все реплики со временем придут к согласованному состоянию.
В отличие от strong consistency, модель работает асинхронно. Узел может подтвердить запись до синхронизации с остальными репликами. Изменения распространяются по системе постепенно, создавая окно времени, когда разные клиенты могут видеть разные версии данных.
Техническая реализация включает векторные часы, конфликт-резолверы и gossiping-протоколы для эффективного распространения изменений. Решение конфликтов обычно строится на принципе "последняя запись побеждает" или через более сложные механизмы слияния.
Яркий пример — DNS-система. Когда меняется запись, обновления распространяются по DNS-серверам не мгновенно. Кто-то может видеть новый IP, кто-то — старый, но в течение TTL все системы синхронизируются. Другие примеры — CDN, социальные сети, большинство NoSQL баз.
Преимущества очевидны: высокая доступность, низкая латентность, отличная устойчивость к сетевым разделениям. Система продолжает работать даже при потере связи между датацентрами. Кластеры легко масштабируются географически, поддерживая локальную запись с отложенной репликацией.
Обратная сторона — борьба с аномалиями согласованности. Разработчикам приходится заранее продумывать, как система будет реагировать на конфликты данных, внедрять идемпотентные операции и проектировать UI с учётом возможных несоответствий.
Выбор между eventual и strong consistency — всегда компромисс между доступностью и мгновенной согласованностью, между скоростью и надёжностью. Если ваше приложение может корректно функционировать без строгой синхронизации всех реплик — eventual consistency даст значительный прирост в производительности и отказоустойчивости.
🏴☠️ @happy_devops
Eventual consistency — модель согласованности, ставшая фундаментом современных распределённых систем. Ключевая идея проста: система гарантирует, что при отсутствии новых обновлений все реплики со временем придут к согласованному состоянию.
В отличие от strong consistency, модель работает асинхронно. Узел может подтвердить запись до синхронизации с остальными репликами. Изменения распространяются по системе постепенно, создавая окно времени, когда разные клиенты могут видеть разные версии данных.
Техническая реализация включает векторные часы, конфликт-резолверы и gossiping-протоколы для эффективного распространения изменений. Решение конфликтов обычно строится на принципе "последняя запись побеждает" или через более сложные механизмы слияния.
Яркий пример — DNS-система. Когда меняется запись, обновления распространяются по DNS-серверам не мгновенно. Кто-то может видеть новый IP, кто-то — старый, но в течение TTL все системы синхронизируются. Другие примеры — CDN, социальные сети, большинство NoSQL баз.
Преимущества очевидны: высокая доступность, низкая латентность, отличная устойчивость к сетевым разделениям. Система продолжает работать даже при потере связи между датацентрами. Кластеры легко масштабируются географически, поддерживая локальную запись с отложенной репликацией.
Обратная сторона — борьба с аномалиями согласованности. Разработчикам приходится заранее продумывать, как система будет реагировать на конфликты данных, внедрять идемпотентные операции и проектировать UI с учётом возможных несоответствий.
Выбор между eventual и strong consistency — всегда компромисс между доступностью и мгновенной согласованностью, между скоростью и надёжностью. Если ваше приложение может корректно функционировать без строгой синхронизации всех реплик — eventual consistency даст значительный прирост в производительности и отказоустойчивости.
🏴☠️ @happy_devops
🔥2🌭1
Forwarded from monhouse.tech
Дорогие друзья, уже на следующей неделе, 23 апреля в Амфитеатре Санкт-Петербургского конгресс-центра Ленполиграфмаш состоится очередной [ Big Monitoring Meetup ] 12!
Программа посвящена мониторингу и включает доклады по тематикам разработки, связи, менеджменту. BMM - площадка, где встречаются профессионалы и энтузиасты отрасли, чтобы обсудить современные тренды, обменяться опытом и найти новые решения для актуальных задач.
Нетворкинг, дружеская атмосфера, способствующая открытому общению и обмену знаниями. Одной из главных ценностей нашей конференции является возможность установить прямой контакт между разработчиками и пользователями.
Встречайте докладчиков двенадцатой конференции:
Презентация "3D визуализация в мониторинге: модный тренд или рабочий инструмент?"
— Андрей Никифоров. Генеральный директор [ ООО «ТРИТВИН» ]
Дискаверинг и мониторинг сетевого оборудования в системе мониторинга Saymon, часть вторая.
— Дмитрий Хандыго. Начальник отдела программных решений [ Inline Technologies ]
Мониторинга много не бывает. Или бывает? А наследованного и самописного?
— Михаил Еграмин. Главный инженер [ ООО «Сети ВЕБА» ]
Мониторинг не ограничен потреблением. Как FinOps помогает не упустить контроль над инфраструктурой.
— Гуляев Андрей. Руководитель развития продукта [ Инферит Клаудмастер ]
Облачная система мониторинга радиовещания.
— Александр Орлов. Менеджер [ ООО "Тракт-Софт" ]
Мониторинг — это просто.
— Вадим Исаканов. Старший инженер [ Платформа контейнеризации «Боцман» ]
Если инциденты случаются - значит это кому-нибудь нужно?
— Вероника Шапиро. Руководитель направления инфраструктурного мониторинга [ CLOUD.ru ]
Не упустите шанс стать частью профессионального сообщества, получить новые знания и вдохновение для развития своих проектов!
✔️ Зарегистрируйтесь сейчас, количество билетов ограничено
Подпишитесь на наш ТГ канал или ВК сообщество, чтоб не пропустить важные новости
До встречи на конференции [ Big Monitoring Meetup ] 12!
Программа посвящена мониторингу и включает доклады по тематикам разработки, связи, менеджменту. BMM - площадка, где встречаются профессионалы и энтузиасты отрасли, чтобы обсудить современные тренды, обменяться опытом и найти новые решения для актуальных задач.
Нетворкинг, дружеская атмосфера, способствующая открытому общению и обмену знаниями. Одной из главных ценностей нашей конференции является возможность установить прямой контакт между разработчиками и пользователями.
Встречайте докладчиков двенадцатой конференции:
Презентация "3D визуализация в мониторинге: модный тренд или рабочий инструмент?"
— Андрей Никифоров. Генеральный директор [ ООО «ТРИТВИН» ]
Дискаверинг и мониторинг сетевого оборудования в системе мониторинга Saymon, часть вторая.
— Дмитрий Хандыго. Начальник отдела программных решений [ Inline Technologies ]
Мониторинга много не бывает. Или бывает? А наследованного и самописного?
— Михаил Еграмин. Главный инженер [ ООО «Сети ВЕБА» ]
Мониторинг не ограничен потреблением. Как FinOps помогает не упустить контроль над инфраструктурой.
— Гуляев Андрей. Руководитель развития продукта [ Инферит Клаудмастер ]
Облачная система мониторинга радиовещания.
— Александр Орлов. Менеджер [ ООО "Тракт-Софт" ]
Мониторинг — это просто.
— Вадим Исаканов. Старший инженер [ Платформа контейнеризации «Боцман» ]
Если инциденты случаются - значит это кому-нибудь нужно?
— Вероника Шапиро. Руководитель направления инфраструктурного мониторинга [ CLOUD.ru ]
Не упустите шанс стать частью профессионального сообщества, получить новые знания и вдохновение для развития своих проектов!
Подпишитесь на наш ТГ канал или ВК сообщество, чтоб не пропустить важные новости
До встречи на конференции [ Big Monitoring Meetup ] 12!
Please open Telegram to view this post
VIEW IN TELEGRAM
🌭1
Forwarded from ProIT Fest
🔥 База знаний тимлида: как въехать в процессы быстро и безболезненно! Подкаст Виктор Корейша и Андрея Синицыны.
Секция: Hype
Кому будет полезно:
➖Тимлидам, которые недавно вошли в новую команду или готовятся к переходу
➖ Инженерам, у которых всё держится в голове и пора с этим что-то делать
➖ Всем, кто хочет структурировать знания о людях и технологиях, не теряя в темпе
✅ О чем?
Как собирать и систематизировать знания в удобных инструментах (например, Obsidian), чтобы понимать, как всё работает — от кода до коммуникаций.
⬇ Что вас ждет?
➖ Рекомендации по ведению личной базы знаний
➖ Как фиксировать не только техпроцессы, но и “социальную архитектуру” команды
➖ Инструменты и лайфхаки для заметок, которые реально работают
➖ Обсуждение Obsidian и подходов к организации данных
👀 Кто спикеры?
Виктор Корейша — Руководитель направления Managed Services в Ozon.
Андрей Синицын — адепт blameless culture, руководитель платформенного отдела в Ozon. Профи в эксплуатации, поклонник SRE и автор телеграм-канала HappyDevops.
PRO IT Fest V
5–6 июля
Санкт-Петербург, пр. Медиков, 3, корп. 5
Конгресс-центр «Ленполиграфмаш»
Билеты
Telegram-бот в котором можно получить скидку до -20%
Секция: Hype
Кому будет полезно:
➖Тимлидам, которые недавно вошли в новую команду или готовятся к переходу
➖ Инженерам, у которых всё держится в голове и пора с этим что-то делать
➖ Всем, кто хочет структурировать знания о людях и технологиях, не теряя в темпе
Как собирать и систематизировать знания в удобных инструментах (например, Obsidian), чтобы понимать, как всё работает — от кода до коммуникаций.
➖ Рекомендации по ведению личной базы знаний
➖ Как фиксировать не только техпроцессы, но и “социальную архитектуру” команды
➖ Инструменты и лайфхаки для заметок, которые реально работают
➖ Обсуждение Obsidian и подходов к организации данных
Виктор Корейша — Руководитель направления Managed Services в Ozon.
Андрей Синицын — адепт blameless culture, руководитель платформенного отдела в Ozon. Профи в эксплуатации, поклонник SRE и автор телеграм-канала HappyDevops.
PRO IT Fest V
5–6 июля
Санкт-Петербург, пр. Медиков, 3, корп. 5
Конгресс-центр «Ленполиграфмаш»
Билеты
Telegram-бот в котором можно получить скидку до -20%
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Можно! Митап состоит из четырех частей:
При покупке билета в боте задай свой вопрос, выбери ментора среди экспертов и получи совет о том, что сейчас реально работает
Честное слово, ивент будет эпохальный, сильно расстроитесь, если пропустите!
И ребята тоже расстроятся, если вас не увидят, так что скорее залетайте и регайтесь!
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4❤3😍3