Обзор архитектуры и подсистем деплоя и мониторинга.
Как инженеры делают систему прозрачной для разработки.


1) Схема организации репозитория puppet.
Зачем мы сделали репозиторий публичным внутри компании?
Как мы "делим" puppet, и что делать, если все "пропало"?
Собственная реализация механизма puppet kick.

2) Как рассказать всем обо всем и никого не потерять.
"Черный мониторинг" (rbmon). Как мы собираем информацию о серверах и демонах.
Делимся логами с разработчиками. Почему написали "велосипед"?

3) Graphite - система сбора и визуализации данных.
Почему graphite?
1М метрик в минуту?
Какие метрики мы рисуем (nginx-graphite-module, rbmon plugins).
Визуализация работы проекта (Dashboard пульт).

Строим CI/CD в Bamboo, используя Chef
-----
Мы покажем эволюционный путь нашего CI/CD-процесса от маленького скрипта на python, до фреймворка на ruby:
+ рассмотрим типичные трудности, возникающие при построении CI/CD процесса с помощью CI-движка и Configuration management tools.
+ покажем реализованные решения на примере связки Chef + Bamboo:
o унификация деплоймент-процесса компании;
o деплойменты на гетерогенные environment'ы, включая Linux/Windows системы;
o инструментарий для построения CD-процесса в Bamboo.

Управление билд-фермой Bamboo с помощью Chef
-----
Для поддержки SDLC-процесса компании мы эксплуатируем большую географически распределенную гетерогенную билд-ферму агентов (80+ агентов на базе Windows, Linux и MacOS). С ростом количества билд-конфигураций и агентов мы столкнулись с задачей управления конфигурациями билд-агентов, с которой успешно справляемся с помощью решения на базе Chef.
Примеры решаемых задач:
+ настройка Bamboo-агентов с нуля;
+ сapability management при помощи ohai;
+ повышение эффективности использования билд-фермы.

Год назад у нас в компании еще никто специально не занимался серверами и их конфигурацией.

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

Чтобы исправить положение мы сделали следующее:
* завернули всю конфигурацию в Chef;
* для управления конфигами приложений начали использовать augeas (у нас большие и часто меняющиеся конфиги;
* теперь ежедневно автоматически собирается образ сервера со всеми установленными и настроенными приложениями последней версии, из которого разработчики при помощи Vagrant могут создавать себе сервера по мере необходимости, не отвлекаясь на установку, обновление и настройку;
* Ежедневно Jenkins из того же образа Vagrant-ом поднимает сервера и прогоняет на них тесты.

Теперь наши разработчики спокойно спят ночами, вместо того, чтобы спешно фиксить баги.
Процесс разработки стал более предсказуемым. Скорость исправления багов возросла. Все счастливы.

Как службе эксплуатации справиться с интенсивным ростом компании? Как поставлять ПО быстро и безопасно в продукт с множеством зависимых компонентов? Как распространить ответственность за эксплуатацию среди инженерных подразделений? Я расскажу про опыт, который мы получили в Spotify, возможно это поможет ответить на данные вопросы.

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

Я расскажу:
- чего удалось добиться за 3 года;
- далеко ли могут увести вас чисто инструментальные решения;
- с какими управленческими проблемами приходится столкнуться, если вы "внедряете DevOps";
- какой может быть предел влияния у "DevOps команды";
- типичные ситуации, в которых можно легко "завязнуть", и их корневые причины.

Возможно ли использование практик и подходов DevOps, CD в корпоративной среде?

Какие особенности?

SPARC + Unix (Solaris)

Вертикальное масштабирование и как следствие — разная конфигурация в бою и на стейдже.

Жесткое разделение сегментов и зон ответственности (разработка без доступа даже к логам, прикладные админы без прав рута, системные админы, слабо понимающие конкретный прикладной сервис).
Ультра-радикальное противостояние всех ячеек друг против друга.

Финансовые сервисы 24*7, невозможно останавливать приложение днем даже на 5 минут. Плановые работы только с 1 до 2 ночи.

Много бизнес-логики в СУБД (Oracle). Невозможно обновлять систему без останова даже в условиях кластеризации.

Как итог — нет возможности ставиться по несколько раз в день или хотя бы каждый день.

Среда до уровня middleware включительно готовится для развертывания нового инстанса вручную системными администраторами.

Дистрибутив передается через файловую шару.

Инструкция по установке — огромная портянка в Confluence с множественными noformat вставками. Точечная автоматизация на Bash-е.



Путь самопознания через боль

Про девопс не знаем ничего, гордо живем в ультраспецифичной "особенной" среде финансовых сервисов. Подходы 80-х. Давайте меняться. Зачем? 30 лет работало, значит хороший подход!!!
Вы, главное, поменьше версий ставьте, а то у вас каждую неделю проект запускается — бардак!!! Но как же так? Бизнес же должен развиваться? Развиваться нужно вдумчиво!!! Качество, скорость и стоимость — выберите два из них и...
Да к черту. Пока вы выбираете 2 из 3 придут стартаперы, которые на новых подходах сделают 3 из 3 и мы останемся у разбитого корыта.


Начали меняться. Манифест о разграничении ответственности и сопровождения и админов. Админы думают, а не исполняют команды, которые мы за них напишем. Интенсивность версий и частота запуска проектов — данность, будет только больше. Это дождь. Не спорь — адаптируйся.
Как итог — 2-е из 4-х админов уходят в другие сервисы, где можно жить по-старому. Ну и что, мы идем дальше. Балласт не нужен.

Этого мало. Простои из за кривых настроек на боевой, проблемы с развертыванием новых модулей, затяжные ночные работы с побудкой всех по ружью. Что делать? Ок, ITIL.
Внедряем Релиз менеджмент и управление изменениями.

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

После изменений на боевой — о чудо!!! убеждаемся, что в результате получилось то, что хотели.

Параллельно работа с разработчиками. Фича готова только тогда, когда на боевой пошли транзакции, и они обрабатываются правильно. Для разработки убираем Shit Umbrella.
Отныне — коллективное владение всем дерьмом, что летит от клиентов!



Когда убрались в комнате, стало ясно что все обветшало
Управление релизами и конфигурациями позволило практически исключить простои из-за некорректных изменений, и сделало прозрачным вынос обновлений. Однако прозрачность не добавила успешности. Много детских ошибок:
1. Огромное количество одинаковых ручных операций на эталонном и затем боевом комплексах. Ошибки человеческого фактора.
2. Дистрибутив через шару — периодически выкладываем не то, ставим не туда.
3. Прикладная логика ведет себя на боевой не так, как на разработке в силу различия конфигурации.
4. Архитектурные решения, принимаемые разработчиками в отрыве от саппорта и админов, при выносе на реальную конфигурацию оказываются не приемлемыми. Обсуждение на предустановочной встрече — слишком поздно.

Что же делать? Помню в 2012 году разработчик приехал с конференции HighLoad++ и рассказывал про доклад некоего Титова по управление конфигурацией. Приставал тогда ко мне этот разработчик с каким-то Chef-ом. Какой-то админский бутор со скриптами для автоматизации конфигурации. Не, это не то, я же тогда CMDB внедрял. Мне надо контролировать конфигурацию, а башскрипты админы и сами могут написать.

Хм... ну внедрил ты CMDB — легче стало? Нет :( Так может все-таки посмотрим, что это за чиф такой.
Читаю, выхожу на ДевОпс, читаю про девопс бессонными ночами, читаю Феникса, статьи, смотрю доклады — и понимаю — так ведь решают наши проблемы? Это же ведь то, что надо.

К сожалению, не все так просто. Разграничение зон ответственности, полная изоляция ИТ о Дева, ну и наконец Unix!

Но мы можем с чего-то начать! Давайте двигаться.

Что сделали:
1. Регулярная синхронизация производственного стейджа с боевой схемой развертывания.
2. Включение прикладного сопровождения в продуктовые команды, участие в выработке правильных архитектурынх решений.
3. Процесс управления доступностью, анализ всех проектов с точки зрения паттернов высокой доступности.
4. Переход на IPS для передачи дистрибутивов.
5. Организация полного конвейера для джава приложений с производственных комплексов на бой при помощи чиифа. В процессе — выкатка веб-приложений. Пока только выкатка...
6. Одно приложение целиком выносим паппетом, для разнообразия.
7. Есть еще виндовс приложения. Пробовали и используем РМ, но это какой то отстой...
8. Веб-приложения катим в онлайне, кластеризация на апаче.
9. Патчи на Оракл катим в онлайне, благодаря технологии EBR.
10. Тестирование и отладка рецептов на нодах vagrant.
11. Команда ДевОпс... тут поговорим отдельно.


Когда удалось донести и до разрабов и до админов пользу от CD и ДевОпс, руководители отделов начали выстраивание двух конвейеров. И если это начиналось с прицелом на их смычку в итоге, то руководитель администраторов постепенно все больше и больше фрустрировал от новой роли своего отдела, от размытия изоляции, от вливания в команду.
В итоге дошло до того, что он физически спрятал в недра своего redmine-а всю свою документацию по проекту. И по сути мы получили двух уродов братьев близнецов DevDevOps & OpsDevOps

Так продолжаться не могло. В результате админами работы по проекту были полностью прекращены. Все рухнуло. Что же делать?
Старый рецепт — балласт в к черту. Предложили админам — кто хочет, перейти к нам, в продуктовую дирекцию. Объявили, что отказываемся от услуг прикладных админов не в нашей дирекции.
Все, кроме руководителя, перешли.

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

Планы до конца года:
1. Выкатка всего, кроме СУБД, рецептами.
2. Начать изменения конфигурации также рецептами.
3. Виндовс приложения на паппет.
4. Oracle Linux пробовать.
5. MCollective.
6. Получить рута и готовить окружение также рецептами.

Чего мы не сможем получить никогда:
1. Обновления каждый день. Максимум — 2 раза в неделю
2. Docker — да, увы, Юникс.
3. Горизонтальное масштабирование и стотыщь нод — не наш путь.
4. Версия Х с чистого листа на любой ноде. Логика в БД еще очень надолго...

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

В докладе будет описан процесс адаптации ванильного OpenStack под нужды сервис-провайдера и представлено наше видение виртуального приватного облака, которое было построено нами на базе OpenStack.

Мы затронем проблемы ванильного OpenStack и расскажем с чем столкнулись на пути его адаптации.
А также представим новую услугу, которую мы запустили, - "Виртуальное приватное облако" - и расскажем о проблемах, которые мы помогаем решать при её помощи.

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

Я расскажу про наш путь от dev-кластера со свалкой кода до платформы, предоставляющей изолированные окружения. Это хороший пример автоматизации деплоя сложной распределенной системы с помощью configuration management-инструментов.

Стек технологий:
- AWS;
- Chef;
- Packer;
- Python;
- Teamcity.

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

Я расскажу про основные инструменты и подходы в тестировании инфраструктуры, как все это автоматизировать и про наш опыт в Express 42. Начиная с анализа кода, интеграционных тестов и заканчивая использованием CI систем. Также расскажу про публикацию инфраструктурного кода в open source.

Доклад будет интересен пользователям любой из систем управления конфигурацией - Chef, Puppet, Ansible или SaltStack.

* Сервис-ориентированная архитектура - что это такое и зачем это нужно?
* Поиск сервисов: стандартные пути:
1) Хардкод endpoint'ов (IP:port).
+ работает
+ просто и топорно
- при росте числа сервисов начинается ад
- появляется документация, странички в вики, которые неактуальны, ночью изменения не внесешь
- при миграции серверов часто меняются эндпоинты, много лишней сопутствующей работы
2) DNS, плюсы, минусы.
+ работает
+ достаточно просто
- необходимо вносить изменения в днс
- асинхронность применения изменений
- лаг, даже при малом TTL
- при миграции серверов нужны ручные действия
- странички в вики и т.п. продолжают существовать и продолжают быть такими же неактуальными.
- при росте числа сервисов веселее не становится
* Появляются сотни сервисов. Потом тысячи. Что делать?
1) Системы управления конфигурацией.
* медленная скорость внесения изменений (минуты и часы вместо секунд)
* иногда затруднён бутстрап нового сервиса
* страничка в вики всё еще нужна
2) Системы service-discovering
* что это такое и как это работает? анонсы о сервисах, использование клиентских сервисов
+ почти реалтайм
+ не требуется страничка в документации
- сложновато для поднятия
- "а вдруг развалится?"
- в идеале требуется модификация приложения
3) Etcd + iptables/haproxy + confd
* Etcd - что это такое и как работает? Etcd vs Zookeeper
* iptables/haproxy - инкапсуляция связи между сервисами в отдельный сервис
* endpoint'ы с точки зрения приложения не меняются никогда. Приложение всегда идет в 127.0.х.y:Z, etcd+iptables+confd обеспечивают правильную связность сервисов
* если приложение хочет больше контроля, оно может ходить в etcd само
* оптимизация большого количества iptables-правил, автоматическое раскидывание правил по цепочкам в древовидном виде
4) выводы

1. Введение в проблематику: файловые хранилища, их классификация и ключевые характеристики - по версии докладчика.
1.1. Термины и определения: файл, хранилище, POSIX file system, документ-ориентированное хранилище, области применимости и условия эксплуатации.
1.2. Классификация по размеру: количество записей, количество байт, количество запросов, количество обновлений и сочетание этих параметров, позволяющее назвать хранилище “большим”.
1.3. Требования бизнеса: бизнесу нужна информация, а не ее хранилища.
2. Два с половиной года эксплуатации в проекте Setup.Ru: попытка систематизации опыта.
2.1. Исторический экскурс.
2.1.1. Начало 2012: традиционный подход, локальная FS и rsync.
2.1.2. Середина 2012: проблема обеспечения отказоустойчивости, первая версия binstore (PostgreSQL based).
2.1.3. Весна 2013: проблемы самописной синхронизации и длинных транзакций.
2.1.4. Весна 2014: исчерпаны возможности вертикального масштабирования, требуется внедрение шардинга.
2.1.5. Начало 2015: проблемы эксплуатации LoeFS и поиски альтернативного решения.
2.1.6. Весна 2015: отказоустойчивое версионированное транзакционное документ-ориентированное хранилище на базе NoSQL кластера (на момент написания тезисов находится на этапе внедрения, выход на промышленную эксплуатацию намечен на 30 апреля 2015 года).
2.2. Эволюция наших представлений об отказоустойчивости и распределении нагрузки.
2.2.1. Меры по обеспечению отказоустойчивости, традиционный подход дал сбой: короткий downtime важнее 100% сохранности данных.
2.2.2. Меры по обеспечению должной производительности на большом общем объеме и маленьком hot set: все упирается в файловый кэш.
2.2.3. Распределенные системы хранения как решение проблем и как источник новых.
2.2.3.1. Проблемы асинхронной репликации: eventual consistency.
2.2.3.2. Проблемы синхронной репликации: задержки.
2.2.3.3. Проблемы систем с выделенной master node: отказоустойчивость.
2.2.3.4. Проблемы систем shared nothing: консистентность.
2.2.3.5. Ребалансинг: почему он создает проблемы, и почему от него нельзя отказаться.
2.3. Поиск решения: проблема, решение, ожидаемый результат, побочные эффекты.
2.3.1. РСУБД PostgreSQL.
2.3.1.1. Очень хорошо для маленьких файлов.
2.3.1.2. Очень плохо для больших файлов в BLOB.
2.3.1.3. Слишком легко сделать сложно: дополнительные индексы потребляют память, сложные join потребляют процессор.
2.3.2. Собственная репликация: изобретение велосипеда.
2.3.2.1. Репликация v1: внешняя line-by-line асинхронная.
2.3.2.2. Репликация v2: длинные транзакции, sequences и eventual consistency.
2.3.2.3. Отказ от собственной репликации: наше представление о распределенных хранилищах не выдержали столкновения с реальностью.
2.3.3. Большое хранилище и проблема удаления файла.
2.3.3.1. Как ни странно, сама поддержка такой возможности резко усложняет систему.
2.3.3.2. Защита авторских прав: поддержка удаления неизбежна.
2.3.4. Технологические ловушки.
2.3.4.1. Невозможно сменить технологию в спокойном режиме.
2.3.4.2. java лучше, чем erlang.
2.4. Современное состояние дел: в каких условиях и для решения каких задач создается новое хранилище.
2.4.1. Горизонтальное масштабирование: других вариантов нет.
2.4.2. Индексы должны помещаться в память.
2.4.3. Кластер должен:
2.4.3.1. обеспечивать replication factor 3;
2.4.3.2. обеспечивать ребалансинг при добавлении новой нод;
2.4.3.3. выполнять полезную работу во время ребалансинг;
2.4.3.4. отвечать на запросы до последней живой реплики!
3. Попытки поиска альтернативы.
3.1. Большая отказоустойчивая СХД: дорого.
3.2. Распределенные POSIX-совместимые файловые системы: созданы под другие задачи.
3.3. Общие проблемы:
3.3.1. минимизация стартовых вложений;
3.3.2. минимизация технологической новизны.
3.4. Попытка анализа стоимости внедрения и владения для разных вариантов.
4. Заключение и выводы:
4.1. Краткое описание разработанной нами системы: отказоустойчивое версионированное транзакционное документ-ориентированное хранилище на базе NoSQL кластера.
4.1.1. Базовая СУБД.
4.1.2. Сценарии использования.
4.1.3. Возможные узкие места.
4.1.4. Цифры и графики: объемы и производительность.
4.2. Прогноз развития событий на ближайший год.

* RTO - Recovery Time Objective - максимальное время, за которое все ваши бизнес-задачи должны полностью быть восстановлены в работоспособное состояние после полной катастрофы ДЦ
RPO - Recovery Point Objective - максимально приемлемый для ваших задач промежуток времени, за который вы готовы потерять данные.

* Стратегии защиты и репликации ДЦ (1 to 1, 1 to many, many to many).

* Асинхронная репликация - наилучший выход с точки зрения производительности, единственно возможный вариант в случае значительного географического разнесения дата-центров (сотни и более километров). Работает на уровне виртуальных машин.

* Метро / "растянутые" кластеры - нулевой RPO, минимальный RTO, большие потери производительности и множество ограничений. Иногда - единственный выход, если уровень приложения не умеет реплицировать данные. Работает на уровне синхронизации датасторов (и всех записей в них).

* Лучший подход - комбинация репликации на уровне приложений, асинхронной и синхронной репликации.

* Технологии Нутаникс для решения подобных задач: DR, Metro cluster, Timestream.

* Timestream - "аналог" TimeMachine, безлимитное количество снапшотов данных без потери производительности и практически мгновенным восстановлением. Работает для всех основных гипервизоров, включая KVM.

* Полный контроль над политиками защиты.

* RESTful API для обеспечения DR / Metro / Timestream.

* Пример (с высоты птичьего полета) архитектуры одного из крупнейших за последние годы IT-проектов государственного / федерального масштаба в РФ, базирующегося на технологиях Nutanix и управляемого KVM Management tool, разработанной нашей компанией. Асинхронная репликация дата-центров на сотни километров, защита данных от реальных катастроф.

Почти год назад мы завершили проект по универсальному мониторингу и в процессе приобрели кучу секретных знаний и умений, которыми хотим поделиться:
* как сделать мониторинг простым, отказоустойчивым и горизонтально масштабируемым;
* как понять, что важно, что не важно, а что важно, но чуть-чуть;
* полезные логи: конвертация логов в метрики и обратно;
* как диагностировать реальные проблемы и отличить их от ложной тревоги (на примере связки js-фронтенд + балансеры + java-бэкенд);
* и, конечно же, как внедрить практики DevOps посредством мониторинга (и подготовить разработчиков к тому, что они ответственны за алерты).


Стек мониторинга: sensu, graphite, cassandra, logstash, heka, influxdb, elsticsearch, chef, statsd, nginx.
Стек поддержки: js, java, erlang, lisp, python, ruby, nginx, mysql, haproxy

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

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

В hh.ru мы используем систему мониторинга ещё и как check list для повседневных задач админов (алерты в данном случае являются задачами для человека: сделал задачу - триггер проверил результат и погас), идея взята из TDD.

Также расскажу, как мы работаем с внештатными ситуациями: реагируем на алерты, чиним, разбираем и классифицируем.

Еще на основе разобранных инцидентов мы считаем показатели работы службы эксплуатации, из этих показателей высчитываются наши премии (данный KPI получился удачным: с ним согласен и бизнес и админы).

Выбор системы мониторинга - это практически holy-war-ная тема среди администраторов и разработчиков. Какая система лучше? Что удобнее? Какая система сможет выдержать большое количество статистики, а какая - лучше собрать и представить данные?

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

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

1) Что именно необходимо мониторить в высоконагруженном (и не только) проекте 24/7?
1.1) Мониторинг потребления ресурсов.
1.2) Статистика работы серверного ПО.
1.3) Бизнес-логика приложения.

2) Обзор существующих open-source (cacti,zabbix,graphite,nagios) систем мониторинга.
2.1) Сравнение возможностей.
2.2) Примеры конфигурирования для мониторинга типовых параметров сервера.
2.3) Плюсы, минусы, подводные камни.

3) Какие существуют SAAS-решения для мониторинга?
3.1) Описание отличий от open-source.
3.2) Примеры использования.
3.3) За и против использования SAAS.

Основной задачей мониторинга является оповещение о проблемах. Я расскажу о том, как сделать так, чтобы все сообщения от Zabbix были наполнены смыслом. Отвечу на главные практические вопросы, связанные с обнаружением проблем. Как избавится от ложных срабатываний и flapping? Как научиться формулировать проблемные и штатные ситуации на родном языке, а не довольствоваться рамками модели простых пограничных значений? Как обнаруживать аномалии?

Как понять, что проблемы больше нет? Зачастую это совсем непросто!

Очень надеюсь, что мой доклад позволит качественно улучшить мониторинг, что хорошо отразится на всей вашей команде.

И, конечно же, я буду рад поделиться своими мыслями о Zabbix 3.0 и дальнейшим направлением развития продукта.

Приходите все те, кому интересен мониторинг. Знание Zabbix желательно, но совсем не обязательно.

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

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

В рамках доклада будут рассмотрены стандартные утилиты, такие как ping, traceroute, mtr, hping, а также области их применения. Самым значительным ограничением при использовании данных утилит является невозможность определения обратного пути пакета, что может значительно усложнить диагностику.

Также в докладе будут рассмотрены активные методы диагностики сетевых аномалий (Looking glass, RIPE Atlas, NLNOG RING, PlanetLab) и разработанный командой Qrator механизм определения обратного маршрута от любой заданной сети с использованием математического моделирования.

Общественное мнение привыкло отказывать нам в признании нашей профессии хоть сколько-нибудь уникальной и творческой. Системный администратор — это такой сантехник по компьютерам, а DevOps — это такой, типа, программист, которому Java не дают, чтобы он случайно своих не перестрелял. Системные администраторы и DevOps'ы не ездят на белых лимузинах, и девушки не кидают в них свое нижнее белье.

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

Задача казалась очень простой — у нас есть несколько клиентов с относительно небольшими кластерами машин (от 8 до 20), и нам необходимо было обеспечить сбор и хранение логов, поиск по ним, сбор метрик, алертинг по ним и рисование графиков. Я представлял себе решение этой задачи два года назад и даже делал об этом доклад в Ульяновске, но что-то пошло не так...

К счастью, наши добрые друзья разработчики, которым вечно не хватает строчек в резюме, создают и изучают новые языки разработки, такие как Clojure и Go, и чтобы потренироваться, пишут на них что-нибудь. Иногда и нам перепадает. Так появились graphite-beacon, Cyanite, OpenTSDB, InfluxDB, Bosun, Banana, Prometheus, Riemann и некоторые другие. С детства обладая дурной привычкой пробовать на вкус все подряд, я познакомился со многими из этих средств, впрочем, меня гнала нужда, а не любопытство. Что именно за нужда — я и расскажу вам в докладе, а лампочка так и останется невкрученной, потому что сисадмин нужен не для этого.