Please enable JavaScript.

Coggle requires JavaScript to display documents.

SRE (Практики (Иерархия релабилити (Мониторинг, Ответ на инциденты,…

- - - - Borgmon
    - - Prober
  - - - Количество
        
        1-2 инцидента за смену
      - Качество
        
        Работа днём
        
        Не терять контакт с системой
      - Компенсация
        
        Отгул
        
        Деньги
    - - Используется рациональное мышление
      - Понятно куда эскалировать
      - Четко построенные процессы инцидент-менеджмента
      - Blameless postmortem
    - - Возврат пейджера
        
        временная мера
  - - - Triage - первоначальная определение критичности проблемы
        
        Сначала вернуть работоспособность системе, потом искать проблему
      - Анализ логов/корректности работы компонентов
        
        Найти компонент который некорректно отвечает
      - Диагностика
        
        Проверка последних изменений
      - Проверка гипотез
        
        находить подтверждающие/опровергающие факты
        
        вносить активные изменения, чтобы проверить
      - Исправление
        
        Негативные результаты важны
        
        Нужно публиковать
        
        Не всегда возможно воспроизвести проблему на проде
      - Получение отчета об ошибке
        
        Автоматически открывает инцидент со всеми данными
        
        Идеальный содержит информацию том что ожидается, что есть на самом, как воспроизвести
  - - - Контролируемый эксперимент
        
        Откат/восстановление нужно тестировать
      - Изменений кода или конфигурации
        
        Коммуникации
        
        Канаречные релизы для всего
      - Проблемы в автоматизированных процессов
        
        Возможность остановить автоматизированные процессы
    - - Сохранять историю инцидентов
      - Задавайте вопросы: "Что будет если..."
  - - - Командующий - видит общую картину, оценивает состояние
      - Ops (вносят изменения)
      - Коммуникации- оповещает, ведет лог
      - Планирование - заполнение доков, заказывает еду
    - - Не решено в течение часа
      - Нужно привлечение другой команды
      - Проблема видна пользователям
  - - - После любого значительного нежелательного события
  - - - Если первый не откликнулся, алертит второму и т.д.
    - - Все нотификации
        
        Агрегация
        
        Тегирование
      - Анализ
        
        Что делали в прошлый раз
        
        Частота возникновения
  - - - Тесты конфигурации
      - Стресс-тесты
        
        Определить границы
      - Канарееченые тесты
  - - - В зависимости от цели, можно по-разному
      - DNS
        
        Кэширование и большой TTL - плохо
        
        нет ясности откуда пойдут запросы
        
        Просто
      - Virtual Ip Address
    - - Таска
        
        Состояние
        
        Здоров
        
        Отказ
        
        Lame Duck
      - Ограничение коннектов
        
        Ограниченный subset
        
        Случайное подмножество
        
        детерминированное подмножество
        
        четенько
      - Политика балансировки
        
        Раунд Робин
        
        Простой
        
        Least Loaded
        
        Нездоровая нода может очень быстро работать и получит много трафика
        
        Взвешенный
  - - - GPU
    - - CRITICAL_PLUS
      - CRITICAL
      - SHEDDABLE_PLUS
      - SHEDDABLE
    - - Перегружен датацентр
        
        Балансировка между ДЦ не должна допускать такого
        
        не ретраим
      - ПРокси для работы с сетевыми пиками
  - - - Перегрузка серверов
      - Исчерпание ресурсов
        
        CPU
        
        Длина очереди
        
        Количество "живых" запросов
        
        Тред старвейшен
        
        CPU or request starvation (?)
        
        Не попадание в дедлайны RPC
        
        чаще промахиваемся мимо кэша в CPU
        
        Память
        
        Умирающие таски
        
        GC
        
        чаще промахиваемся мимо кэша приложения
        
        Треды
        
        Файловые дескрипторы
        
        Зависимости между ресурсами
    - - Способы
        
        Лоадтестить!
        
        Пронаблюдать failure mode
        
        Отдавать упрощенные результаты
        
        Давать отлуп когда перегружен
        
        Давать отлуп чтобы не перегрузиться
        
        планировать капасити
      - Управление очередью
        
        если нагрузка постояная, лучше меньше
        
        если бывают пики, то ок
      - снижение нагрузки и graceful degradation
        
        shedding
        
        FIFO -> LIFO/CoDel
        
        возвращать 503
        
        graceful degradation
        
        не должно быть часто
        
        мониторить
        
        Как много узлов в таком режиме
      - ретраи
        
        могут легко накапливаться
        
        отличать transient ошибки
        
        randomized exponential backoff
        
        бюджет ретраев
      - лэтенси и дедлайны
        
        думать как выбрать
        
        не должны быть на порядки больше выполнения запроса
        
        распространение дедлайна
        
        распространение отмены
        
        бимодальная лэтенси
      - триггеры
        
        смерть процессов
        
        vykladka
        
        баги в новой версии
        
        органический рост
        
        запланированные работы
        
        ограничение ресурсов
        
        (кто-то мапредьюсит в твоём кластере)
      - Тестирование каскадных сбоев
        
        Посмотреть как себя ведет под лоад тестом
        
        проверить всех клиентов сервиса
        
        Используют ли ретраи
        
        Могут ли создать пиковую нагрузку
        
        проверить зависимости вашего сервиса
        
        что будет если зависимость упадет
      - медленный старт и прогрев
        
        летенси кэш
        
        когда без кэша медленнее отвечаем
        
        капасити кэш
        
        когда без кэша перегружаем кого-то другого или сами перегружаемся
    - - Добавить ресурсов
      - выключить хэлс чеки
      - перезагрузить
      - дропать трафик
      - войти в режим деградации
      - выключить батч нагрузку
      - вырубить плохой трафик
  - - - Не знает о результате выполнения
      - машина с cron может упасть
      - нет идемпотентности в общем случае
    - - Под cron отданы несколько машин
        
        одна из них лидер
        
        на остальных реплицируется расписание
        
        только лидер отдает команды планировщику
        
        стейт персистится
        
        у каждой реплики своя копия стейта
      - запуск джобы
        
        через паксос сообщает о начале запуска
        
        через паксос сообщает что запуск состоялся
        
        запускает джобу
        
        фейловеры сохраняют в стейт инфу о запусках
        
        что происходит если запуск не удался не раскрыто
        
        указывают время настолько неточно, насколько возможно
  - - - Периодические
        
        Проблемы
        
        Зависшие звенья
        
        Неравномерная нагрузка
        
        Нет метрик в процессе
      - Непрерывные
    - - Как MVC (?)
      - Task Master
      - Workers
      - Controller
      - Гарантии коректности
  - - - Проактивное обнаружение
      - Быстрая починка
      - Быстрое восстановление
    - - Бекапы для оперативного ресторы
      - Архивы для долгосрочного хранения
      - Недостаточно делать - надо уметь восстанавливать
    - - Целостность
        
        Репликация и избыточность не дают восстанавливаемость
        
        Retention
        
        Многослойная модель
        
        Мягкое удаление
        
        Ленивое удаление
        
        Бекапы
        
        Ранее обнаружение
        
        Обнаружение как тест
      - Доступность
    - - Восстановление можно видеть
      - Восстановление - конечная цель
      - Команда показывает, что могут восстанавливаться достаточно быстро
    - - Корневые причины
      - Scope
        
        Широкий
        
        Ограниченный
      - Частота
        
        единовременно
        
        Медленно, но верно
      - Корневые причины * Scope * Частоту
  - - - Легковесность
      - Устойчивость к очевидным ошибкам
      - Детальный
      - Масштабируемый
      - Адаптируемый
    - - Поддерживают актуальными и не слишком большими
- - - - Лэтенси ошибок надо отделять
- - - - Каждый сервис говорит об уровне утилизации
    - - Storage
        
        D
        
        Colossus
        
        Cluster wide filesystem
        
        Bigtable
        
        Spanner
        
        Blobstore
    - - IP:port
- - - - одни реквесты важнее других
        
        но зато так проще
    - - гугл уже не бывает недоступен совсем, поэтому уже не так показательно
  - - - решают совместно продуктовая команда и SRE
      - может быть разный для разных юзкейсов
        
        напр. BigTable: latency/throughput
      - у недоступности разная стоимость для разных сервисов
    - - напр. security breach
  - - - тестирование
      - устойчивость к сбоям
      - canary
      - частота релизов
    - - по показателям мониторинга
      - договариваются SRE и продуктовая команда
    - - снижает противоречия между продуктовой командой и SRE
        
        потому что объективен
      - управление скоростью изменений
- - - - что-то почитать
        
        постмортемы
        
        Wheel of Misfortune
        
        ломать и чинить продакшн
        
        ломать до конца
        
        on-call чеклист
        
        студенты его же обновляют
      - что-то поделать руками
        
        реверс-инжиниринг
        
        по мониторингу, например
        
        shadow on-call
        
        reverse shadow
  - - - Фазы
        
        Изучить сервис и погрузиться в контекст
        
        Shadow on-call для оценки необходимости SRE
        
        Определить источники стресса
        
        Найти мины замедленного действия
        
        Шарить контекст. Как быть хорошим SRE
        
        Всегда что-то ломается и это норм.
        
        Драйвить изменения
        
        Объяснять
        
        Задавать наводящие вопросы
  - - - Агенда
        
        Метрики
        
        Падения
        
        События с уведомлением
        
        События без уведомления
        
        Предыдущие решения
      - Кто участники?
      - Длительность 30-60
  - - - Привлечение
      - Анализ - как работает, зависимости, на сколько не соответствует стандартам SRE
      - Рефакторинг - работают над стабильностью
      - Тренинг - документация и обучение команды
      - Onboarding
      - Непрерывное улучшение
    - - Команда SRE привлекается на ранней стадии и учавствует во всех фазах разработки сервиса
    - - Преимущества
        
        Best practicies - зафиксированы в коде
        
        Переиспользование решений
        
        Общая платформа с унифицированными интерфейсами
        
        Проще автоматизировать
- - - - Chubby и planned outages
  - - - слишком много — расфокус
      - слишком мало — не замечаем сбои
      - выбираем то, что важно для пользователей
    - - перцентили вместо среднего
        
        более показательно, потому что показывает распределение
        
        изучаем распределение, не предполагаем нормальное
      - проще — лучше
- - - - Стабильность против скорости
  - - - SE + UNIX internals + networking
      - Software Engineering
    - - Blame free postmortem
    - - Выбирается уровень
        
        Бюджет ошибок
        
        Нет конфликта между dev и ops
    - - Инженер не должен смотреть на мониторинг
      - Алерты
      - Тикеты
      - Логирование
        
        Логи не надо читать
    - - MTTF, MTTR
        
        Playbooks
    - - 70% проблем после изменений на проде
      - Прогрессивная раскатка
      - Быстрое определение проблем
      - Безопасный откат
    - - Текущая мощность достаточно
      - Следят за органическим ростом
      - Следить за событиями, которые могут увеличить трафик
- - - - https://xkcd.com/1205/