Рубрики
Uncategorized

DevOpsdays India 2017.

Первоначально это было опубликовано в моем личном блоге. Devopsdays — это технические конференции, охватывающие … Tagged с DevOps, Conference, TechTalks.

Первоначально это было опубликовано в Мой личный блог .

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

Это место, где люди и компании собираются вместе и делятся своим опытом в отношении того, как они решали различные проблемы, связанные с DevOps.

Devopsdays India 2017 произошел в Бангалоре 16 и 17 сентября, и я впервые посещал конференцию Devopsdays India, и я сделал много заметок. Вот оцифрованная версия моих заметок о различных разговорах, когда я записал/помню их.

Натен Харви ( @nathenharvey ) — вице -президент по развитию сообщества в Программное обеспечение шеф -повара Анкет Если вы хотите выучить шеф -повара, отправляйтесь в Learn.chef.io Для хорошей серии учебных пособий и курсов.

  • Мы инженеры находятся
    • Не привязан к устаревшему техническому долгу.
    • Не вращайтесь облачными серверами.
    • Не просто системы сборки.
  • Ваша основная работа — « Радуйте своих клиентов «.
  • Стройте ➡ Scale ➡ Обслуживание ваших клиентов.
  • Code/Chef/Ansible/все, что вы используете , всегда кладите это в венчурные кадры.
  • Написание тестов (хорошо) против Nagios оповещения (плохо).
    • Написание любых тестовых примеров — это хорошо.
    • Написание отсутствия тестовых случаев — это плохо.
    • Тестовые примеры будут развиваться по мере развития. Так что не имеет значения, не являются ли они всеобъемлющими.

  • Всегда делаю Статический анализ

    • Cookstyle — Проверяет руководство по стилю для сценариев Ruby.
    • FoodCritic — Проверяет руководство по стилю для сценариев шеф -повара.
  • Интеграционное тестирование
    • Начните виртуальную машину.
    • Получите свой код на него.
    • Тест.

  • Используйте Четыре правления глаз

    • Всегда имейте четыре глаза, посмотрите на код, прежде чем подталкивать к производству.
    • Обзор кода является важной частью процесса тестирования.
  • Источник Репо ➡ Артефакт ➡ Артефакт Репо.
  • Информационной безопасности
    • 81% ИТ -специалисты считают, что команда Infosec препятствует скорости развертывания/производства.
    • 77% специалистов Infosec также так думают.
  • Для сотрудничества сделайте все видимыми.
    • Узнайте, где наши ограничения и узкие места.
  • Метрики успеха программного обеспечения:
    1. Скорость
    2. Эффективность
    3. Риск
  • Попробуйте Обнаружение сбоев на ранней стадии Анкет
  • Непрерывное улучшение
    • Учиться активно.
    • Поделиться информацией — метрики/отчеты.
    • Выравнивать стимулы и объекты всех команд.
  • Post Mortem — всегда задайте эти 2 вопроса:
    • Как мы могли обнаружить это раньше?
    • Как мы можем избежать этого в будущем?
  • Знай своего клиента.
  • Сделать работу видимой.
  • Измерить прогресс.
  • Участвовать в сообществе.

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

Как инженеры/разработчики, мы можем создать что -то новое. Но что бы мы ни создавали, если это не решает больной точку клиента, это бесполезно.

Ronak Banka ( @ronakbanka ) работает с Rakuten

Принцип в Ракутене:

  1. Всегда улучшайте. Всегда продвигайся.
  2. Страстно профессиональный.
  3. Гипотеза -> Практика -> Validate -> Shikunika.
  4. Максимизировать удовлетворенность клиентов.
  5. Скорость! Скорость! Скорость!

Болетные точки растущих инструментов автоматизации:

  • Высокая доступность
  • Масштабирование
  • Самосфера инфра
  • Обновления
  • Замок продавца

Используя Бош , выпуск инженерии, развертывания, управления жизненным циклом и т. Д. Становятся проще.

Переход к одной инженерной системе

Сэм Гукенхаймер ( @samguckenheimer ) (Служба команды Visual Studio)

  • В Microsoft до 2011 года у каждой команды была своя собственная база кода, не зависит от команд.
  • Сатья Наделла представил одну инженерную систему. Более открытый.
  • Производительность важнее любой другой функции.
  • PR ➡ Обзор кода ➡ Тестовые примеры ➡ Тест безопасности ➡ слияние для мастерства ➡ Непрерывная интеграция.
  • Проходит 60237 тестов за 6:39 минуты.
  • Существует предел 8 минут для проведения тестовых случаев. Ранее было 10 мин.
  • Ограничение 12 часов для проверки кода. Иначе PR истекает. DEV должен повторно повторно обзор PR/кода.
  • Виртуальная файловая система GIT
    • Linux ядра 0,6 ГБ
    • VSTS 3GB
    • Windows 270GB
    • Общее улучшение в 300X от клонирования до совершения.
  • Метрики для отслеживания
    • Живой сайт здоровья
    • Скорость
    • Инженерный
    • Применение
  • Публикуйте анализ основной причины (RCA) в блоге для более серьезных проблем — большей прозрачности.
  • Присваивая командам
    • У каждого лидера команды есть 2 минуты, чтобы рассказать о своей команде и почему люди должны присоединиться к своей команде.
    • Разработчики могут выбрать 3 команды, в которых они заинтересованы, и их приоритет.
    • Совместите разработчики командам на основе выбора и доступности.
    • > 90% соответствия.
  • Спринты
    • Не думайте, что впереди более 3 спринтов.
    • Слишком много неопределенности и устаревших функций.

Мой вывод: даже огромная организация, такая как Microsoft, может быть сделана для следования передовым практикам. Есть надежда на небольшие стартапы, которые делают вещи Adhoc.

Кишор Джаледа ( @kishorejalleda ), работал в Imvu, Zynga, в настоящее время старший директор Yahoo!

  • Демократизировать инновации
    • Нет карманов инноваций. Например: Инновационная лаборатория.
    • Вы не можете времени и контролировать инновации в определенной команде.
  • Разрешения не требуются для доставки функций до 1% пользователей.

  • Двигайся быстрее. Есть очень высокая скорость .

    • Но конфиденциальность и безопасность не подлежат обсуждению.
  • Вы написали это; у тебя это владеет.
  • Вы написали это; Вы запускаете это.
  • Предупреждение
    • Предупреждение ➡ Команда A ➡ Team B ➡ Team C ➡ Dev.
    • Предупреждение ➡ dev. (намного лучше)
    • Идеально: <2 оповещения/сдвиг, чтобы RCAS возможны.
    • Говорить «нет» сложно, но мощно.
    • Журналы лучше, чем электронные письма для оповещений.
  • Коммитами идут на производство:
    • С участием человека.
    • Без участия человека. (лучше)
    • Нуждается в TDD.
      • Занимает много времени. Много оппозиции. Не каждый покупает.
      • Иметь очень очень высокую скорость
      • Тест Покрытие никогда не будет на 100% — но это нормально. Так же, как есть ошибки в программном обеспечении, это не имеет значения.
  • Автоматизация
    • Не вознаграждайте плохое поведение.
    • Не позволяйте разработчикам Не Автоматизируйте их вещи. Перезапуск сервера каждый день в 3 часа ночи — плохое поведение.

    • Автоматизация позволяет вам делать » Работа с более высокой стоимостью «.

      • Что ты хочешь делать? Перезапустить серверы? или написать производственный код?
    • Перестань говорить то, что не имеет значения.
  • Общественное облако против частных центров обработки данных:
    • Перейти к гибридному подходу, покупать или строить в зависимости от времени и использования времени и использования
    • Если вы делаете вещи, которые не соответствуют остальной части компании: «нарушите правила, но нарушите их среди бела дня».
    • Создайте новые приложения с учетом облака.
  • Стимулировать команды к автоматизации.
  • Наградить хорошее поведение.
  • Двигаться быстро, чтобы оставаться актуальными.
  • Не стремитесь к 100% соответствию.
  • Это процесс, который имеет значение.

Мой вынос: вы не можете получить 100% соблюдение с первого дня. Заставлять всех следовать автоматизации, тестовых примеров, проверки кода, CI/CD сложно. В итоге Люди (если они умны) попадут туда.

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

Радж Рохит ( @data__wizard )

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

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

День 1 закончился несколькими разговорами о молнии, а затем мастерской на Kubernetes.

Абхинав Шрофф — ( @abhinavshroff )

  • Построение приложений умнее — с данными.
  • Системы ML требуют обратной связи — это требует правильной стратегии DevOps и инструментов.
  • Язык
    • Питон
    • R
  • Devtools
    • Затмение
    • Юпитер
    • Rstudio
  • Зачем контейнерировать?
    • Настройка
    • В комплекте
    • Автономный
    • Кластеризация
    • Определенный интерфейс
    • Облачный микросервис
  • Варианты оркестровки контейнера
    • Docker Swarm
    • Kubernetes
    • Apache Mesos
    • (или же)
    • Облако развертывания контейнеров (облачный сервис Oracle Developer)
  • Микросервисы
    • Джупитер ядра шлюз
    • Создайте службу отдыха в ноутбуке Jupyter.

Ханна Мэдли ( @Djpajamapantz ) & Виктория Джеффри ( @vickkoala ) из программного обеспечения Chef.

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

  • Inspec Тестовый бегун

    • SSH
    • Уинрм
    • Докер
  • Inspec Shell
  • Более короткая петля обратной связи очень важна
  • Готов к использованию профилей, доступных на
    • GitHub
    • Супермаркет

По Правин Шукла ( @_praveenshukla ) из Gojek Engineering

Надежность приводит к прибыли бизнеса. Но передать это деловым людям сложно. Это история о том, как инженерная команда Gojek сделала свои системы надежными в масштабе.

  • 100 экземпляров до 8000 экземпляров
  • 1 миллион (внутренняя) транзакции в секунду
  • Надежность
    • Время работы — 4 девян
    • MTBF — время безотказной работы/разбивка
    • Неудача в год (AFR)
    • QOS
    • SLA — 2MS -ответ против 2S ответа, что является надежным?
  • Чтобы определить надежность, сначала определите отказ.
  • Отказ: системы, работающие вне указанных параметров
  • Неудача в соответствии с бизнесом: Пользователи жалуются
  • 2015
    • 4 продукта
    • 10 микросервисов
    • 100 случаев
    • 50+ технологий
    • Скорость против стабильности
  • 2017
    • 18 продуктов
    • 250+ микросервисов
    • 8000+ случаев
    • 3 центра обработки данных
    • AWS, GCE, собственный центр обработки данных
    • 350+ технологий
  • вопросы
  • CI/CD
    • Дженкинс
    • Управление доступом к трубопроводу.
    • Пользовательское развертывание — нужно GOTO команды DevOps/SRE.
    • Управление репозиториями DSL. Код и CI живет в двух разных репо.
    • Нет развертывания на основе филиала
  • Управление конфигурацией
    • Создайте кулинарную книгу для каждого микросервиса.
    • 350+ поваренных книг.
  • Оповещение и мониторинг
    • Оповещения теряются.
    • Не получают оповещения для нужного человека.
    • Слишком много пейджеров слишком многим людям.
    • Кто несет ответственность за то, чтобы принять меры по предупреждению?
  • Решения
  • CI/CD
    • Дженкинс ➡ Гитлаб CI .
    • Bitbucket ➡ Gitlab Анкет
    • CI теперь является файлом YAML и является частью исходного кода.
    • развертывание на основе филиала и тегов.
  • Управление конфигурацией
    • Используйте 4 языка
      • Рубин
      • Голанг
      • Клоджюр
      • Jruby
    • Создайте основную кулинарную книгу для каждого языка
    • 4 кулинарные книги вместо 350
  • Оповещение и мониторинг
    • Умный маршрутизатор оповещения
      • Каждый продукт принадлежит 1 группе
      • Каждая группа имеет много микросервисов
      • Каждый микросервис работает на нескольких серверах
      • Каждый член принадлежит нескольким группам
      • Когда на сервере происходит предупреждение, соответствующая группа получает предупреждение
    • Настройка предупреждения
      • Создать файл yaml
      • подтолкнуть его, чтобы репо
      • CI настраивает оповещение из файла YAML
  • Надежность и зависимость
    • 1 Сервис: R: 99%
    • 1 ⬅ 3 Услуги: R: 97%
    • 1 ⬅ 3 ⬅ 3 Услуги: R: 88%
    • Потерпеть неудачу Быстро Анкет
    • Используйте автоматические выключатели.
    • 99,99% времени безотказной работы для 30 микросервисов дает только 99,7% времени безотказной работы для всей системы.
    • 0,3% от 1 миллиарда запросов ➡ 3 миллиона запросов.
    • 2+ часа простоя каждый месяц
  • Задержка в очереди
    • Масштабирование не может решать каждый раз
    • Ddos убьет это
    • Вместо этого Затомить вашу систему
  • Надежность — это итеративный процесс

По Санчит Бахал (@ sanchit_bahal ) от мысли

Контекст:

Мыслили было предложено построить мобильное приложение для багажа авиакомпании.

Они обычно используют git + GOCD для CI/CD. Но клиент не хотел публичного облака. Таким образом, машины сборки были в доме — микс Mac и VMS Linux.

Они начали испытывать длительное время ожидания сборки, иногда ~ 1,5 дня.

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

Путешествие:

  • Автоматизировать подготовка
    • Используя Ansible Анкет
    • Установка XCODE, Android SDK.
    • Используйте локальный файловый сервер для тяжелых загрузок.
  • Предварительно выпеченное золотое изображение
    • OSX + Ansible ➡ изображение.
    • Используйте Deploy Studio.
    • Новая машина занимает 30 минут вместо 2 дней.
  • Гомогенные сборки
    • Все машины ➡ Все типы сборки.
    • Лучше сбалансирована нагрузку.
    • Лучшее распределение работы.
    • устойчивость.
  • 1 агент сборки за машину
    • Упрощенная настройка.
    • Более легкое распределение рабочей нагрузки.
  • Эмулятор
    • Geny Motion ➡ Эмулятор Android.
    • Genymotion иногда застряла. Неопределенный.
    • Поверните и вращайте эмулятор Android на каждом наборе тестирования.
    • Запустите в режиме без головы.
    • Сохранить на коде лицензирования. 30000 долларов в год для 80 человек.
    • Эмуляторы Android позволяют начинать с чистого листа и заканчивать в чистом листу.
  • DevOps Analytics
    • Измерить улучшения.
    • Непрерывный мониторинг.
    • Действенные идеи.
    • Telegraf + Influxdb + Grafana.
  • Приборная доска
    • Постройте время ожидания — время назначить агента сборки на запланированную работу.
    • Развернуть готовую сборку — время от Commit до создания готового к QA.
    • Создание машин здоровье — нагрузка, процессор, память, диск и т. Д.
  • Результаты
    • Машина Время подготовки: 2 дня ➡ <30 минут.
    • Построить время ожидания: 6 часов ➡ <10 секунд.
    • Стабильная, надежная, устойчивая инфраструктура сборки.
    • Более быстрый цикл обратной связи ➡ больше коммитов/день.
    • Лучшая производительность разработчика.

Мой вынос: производительность разработчика очень важна, а более быстрый цикл обратной связи позволяет вам быстрее совершать код.

Это был молния, разговор Гутам ( @putadent ) студент GSOC, который работал над Прометей Анкет Он говорил о более низком использовании памяти и других улучшениях в v2.0.

Это все еще в бета -версии, но, поскольку Прометеей тянет метрики, на серверах есть как 1.x, так и 2,0. Переключите версии, когда он становится стабильным.

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

От neependra ( @neependra ) — Cloudyuga

Сообщество! Сообщество! Сообщество!

  • Что может сделать сообщество с вашей карьерой
    • Удовлетворение.
    • Получить видимость.
    • Получите работу, которую любите.
    • Начните что -то собственное.
  • Что мешает нам быть частью сообщества
    • Временное обязательство.
    • Компания культура.
    • СТРАХ.
    • Зона комфорта.
  • Создайте бренд для себя.

Это был конец конференции Devopsdays 2017. В целом большинство разговоров было довольно хорошим, и у меня был хотя бы один ключевой вынос из каждого разговора. Из разных разговоров это показывает, что многие люди изо всех сил пытались вызвать изменения в своих компаниях, чтобы привлечь мышление DevOps об автоматизации, TDD, обзорах кода и т. Д.

Оригинал: «https://dev.to/cnu/devopsdays-india-2017-conference-notes»

Читайте ещё по теме: