разработчики пишут код → DevOps автоматизирует его сборку, доставку, запуск и поддержку.
DevOps → SRE (Critical Boundary)
This is a responsibility boundary, not a tooling boundary.
DevOps is accountable for delivery into production. SRE is accountable for production behavior over time.
DevOps asks: “Is it deployed correctly?”
SRE asks: “Does it continue to meet SLO under real failures?”
SRE owns SLOs, error budgets, incident response, postmortems and has authority to block releases.
От себя же добавлю что у нас в России - из-за непонимания DevOps-культуры, эта должность имеет более широкое понимание. И охватывает, по сути, все, что связано с теми, кто работает непосредственно с серверами - это в какой-то степени царь и бог для серверов, которые есть у компании
Это из-за низкого уровня компетенций в понимании смысла разделения ролей. Как пример - буквально сегодня общался с одним маркетплейсом W****s - у них описание SRE-инженера включает в себя следующие роли ниже (ответственность): - Firmware / BIOS / burn-in ->> Platform Hardware Engineer - OS / Kernel / FS / Network ->> System Administrator - Container platform / Application deployment ->> DevOPS - Reliability / Incidents ->> SRE
Не понимают что, 1. Это принципиально разные роли, с разными требованиями к навыкам, психологическому профилю, уровню компетенций, практическому опыту работы, объемом ответственности перед бизнесом. 2. Из-за списка выше, разница, например, в оплате между Platform hardware Engineer и SRE (высшая степень ответвенности перед бизнесом) может доходить до 50%. 3. Непонимание пунктов 1 и 2 выше-это попытка нанять\заманить человека-паука, который через какое-то время либо выгорит и сбежит, либо просто сбежит.
Выше описанное касается и секьюрити вещей - не просто так придуман код-ревью\секьюрити чеки, продецуры ступенчатого контроля за доступами (апрувы).
Основная причина, почему получилась такая вот таблица с качеством -нет системы контроля у отечественных медиасервисов (из тех, которые видел на нашем рынке)
Мы говорим о надежности железа или о работоспособности сервиса? Не понимаю разницы и применения ИЛИ
Не понимаю разницы и применения ИЛИ. Доступость/надежность/availability - это одна из метрик сервиса (я, честно, не понимаю что под работоспособностью имеется ввиду).
Но в статье речь о нескольких серверах из‑за проблем масштабирования. Так что это не повышает надежность сервиса, а только понижает — точек отказа становится больше.
Почитайте как рассчитывается уровень надежности\отказоустойчивости и как это связано с масштабированием. Для современного инженера, работающего на каждом шагу с масштабируемостью и отказоустойчивостью, это обязательные знания. Гугл, Яндекс, Амазон закроются с понедельника, а то у них столько серверов и точек отказа, что нет никакой возможности работать.
Если говорить про vps, то вертикально расти не проще. Бизнес облака - продажа vps с некоторым оверкомитом, который в хорошем облаке, при "средних" задачах/утилизации vps , клиент и не заметит. Чем виртуалка толще, тем сложнее её облаку содержать и у клиента больше рисков пострадать от "шумного соседа"
Ну и 1 толстая vps проиграет по вероятности отказа 3 маленьким vps
Молодцы!Очень хорошая, структурированная статья, особенно в части объяснения\мотивации бизнес-критериев при выборе решения. Я не так часто вижу от Sr. Engineer такой последовательный, рассудительный подход. К сожалению. Большая просьба-наполните раздел документации на Github. У вас отличная статья здесь,и как написали выше, сожмите чуть и в README.md!
Policy Based Routing для IP адреса, сайта, порта, которому хотите поменять страну. Сложнее всего настроить OpenWrt с множественными исходящими VPN, чем в LuCi прописать правила на конкретное локальное устройство
Объём видеохранилища на сегодня составляет более 250 Пбайт, в нём хранится около 400 млн видео и каждый день их количество увеличивается в среднем на 1 млн — столько новых видео пользователи в среднем загружают на платформу.
Прям уж нет контента =)
Сделать рабочий рекомендательный сервис, конечно, посложнее будет, чем сделать CDN. Но не будем терять оптимизма
Аудитория, судя по графикам, вполне есть и, как написано в статье - ребята решали проблему масштабирования сервиса . Вряд ли аудитории будет интересен поиск или рекомендации, если видео не проигрывается, а то и веб-интерфейс не открывается
DevOps → SRE (Critical Boundary)
This is a responsibility boundary, not a tooling boundary.
DevOps is accountable for delivery into production.
SRE is accountable for production behavior over time.
DevOps asks: “Is it deployed correctly?”
SRE asks: “Does it continue to meet SLO under real failures?”
SRE owns SLOs, error budgets, incident response, postmortems and has authority to block releases.
Это из-за низкого уровня компетенций в понимании смысла разделения ролей.
Как пример - буквально сегодня общался с одним маркетплейсом W****s - у них описание SRE-инженера включает в себя следующие роли ниже (ответственность):
- Firmware / BIOS / burn-in ->> Platform Hardware Engineer
- OS / Kernel / FS / Network ->> System Administrator
- Container platform / Application deployment ->> DevOPS
- Reliability / Incidents ->> SRE
Не понимают что,
1. Это принципиально разные роли, с разными требованиями к навыкам, психологическому профилю, уровню компетенций, практическому опыту работы, объемом ответственности перед бизнесом.
2. Из-за списка выше, разница, например, в оплате между Platform hardware Engineer и SRE (высшая степень ответвенности перед бизнесом) может доходить до 50%.
3. Непонимание пунктов 1 и 2 выше-это попытка нанять\заманить человека-паука, который через какое-то время либо выгорит и сбежит, либо просто сбежит.
Выше описанное касается и секьюрити вещей - не просто так придуман код-ревью\секьюрити чеки, продецуры ступенчатого контроля за доступами (апрувы).
У Netflix очень серьезный подход к качеству, включая качество медиаконтента.
Вот статья как они анализируют качество видео (2016г) https://netflixtechblog.com/toward-a-practical-perceptual-video-quality-metric-653f208b9652
Вот основной инструмент для объективного анализа
https://github.com/Netflix/vmaf
Т.е. в свободном доступе есть и методология и инструменты.
Основная причина, почему получилась такая вот таблица с качеством -нет системы контроля у отечественных медиасервисов (из тех, которые видел на нашем рынке)
Не понимаю разницы и применения ИЛИ. Доступость/надежность/availability - это одна из метрик сервиса (я, честно, не понимаю что под работоспособностью имеется ввиду).
Почитайте как рассчитывается уровень надежности\отказоустойчивости и как это связано с масштабированием. Для современного инженера, работающего на каждом шагу с масштабируемостью и отказоустойчивостью, это обязательные знания.
Гугл, Яндекс, Амазон закроются с понедельника, а то у них столько серверов и точек отказа, что нет никакой возможности работать.
Если говорить про vps, то вертикально расти не проще. Бизнес облака - продажа vps с некоторым оверкомитом, который в хорошем облаке, при "средних" задачах/утилизации vps , клиент и не заметит. Чем виртуалка толще, тем сложнее её облаку содержать и у клиента больше рисков пострадать от "шумного соседа"
Ну и 1 толстая vps проиграет по вероятности отказа 3 маленьким vps
Молодцы!Очень хорошая, структурированная статья, особенно в части объяснения\мотивации бизнес-критериев при выборе решения. Я не так часто вижу от Sr. Engineer такой последовательный, рассудительный подход. К сожалению.
Большая просьба-наполните раздел документации на Github. У вас отличная статья здесь,и как написали выше, сожмите чуть и в README.md!
Автору поста, конечно, плюсик за трудолюбие и усердие.
Но зачем!?
Все что описано в посте-team work, parallel programming можно делать с коллегами по работе, не хуже чем в .
Policy Based Routing для IP адреса, сайта, порта, которому хотите поменять страну.
Сложнее всего настроить OpenWrt с множественными исходящими VPN, чем в LuCi прописать правила на конкретное локальное устройство
Объём видеохранилища на сегодня составляет более 250 Пбайт, в нём хранится около 400 млн видео и каждый день их количество увеличивается в среднем на 1 млн — столько новых видео пользователи в среднем загружают на платформу.Прям уж нет контента =)
Сделать рабочий рекомендательный сервис, конечно, посложнее будет, чем сделать CDN. Но не будем терять оптимизма
Аудитория, судя по графикам, вполне есть и, как написано в статье - ребята решали проблему масштабирования сервиса . Вряд ли аудитории будет интересен поиск или рекомендации, если видео не проигрывается, а то и веб-интерфейс не открывается