Как создать простую в использовании цепочку инструментов DevOps

Источник контента:10 июня 2017 года соучредитель Yiwei Technology выступил с речью «Как создать простую в использовании цепочку инструментов DevOps» на конференции Ren Fake «DevOps & SRE Beyond the Way of Traditional Operation and Maintenance». IT big coffee сообщил, что как эксклюзивный видео-партнер, он был выпущен с разрешения организатора и спикера.

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

В ходе этого процесса постоянно упоминаются некоторые проблемы, и нам необходимо неоднократно связываться с продуктами и отделом исследований и разработок.

Почему система устроена именно так? Зачем выбирать несовершенное решение для разработки программного обеспечения? Тот же вопрос, зачем разрабатывать несколько инструментов? Почему опробованные дизайнерские идеи не работают

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

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

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

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

Почему простота и удобство использования так важны?

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

Но когда мы говорим о 2C и когда мы говорим о 2B, простота их использования находится на двух уровнях.

2C подчеркивает, что пользователи должны стараться свести к минимуму то, о чем они думают и принимают решения, и сохранять прилипчивость. Но 2B напрямую влияет на эффективность решения проблемы обязательств.

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

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

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

Уровень реализации отделен, а услуга интегрирована.

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

Создавая систему, мы делаем только одно, и делаем это хорошо. Преимущество этого в том, что 10 систем, выполняющих 10 задач, лучше, чем одна система, выполняющая 10 задач, поскольку она менее сложна.

Универсальные системы в основном антигуманные, предоставляя комплексный обзор только тогда, когда это действительно необходимо.

Разделение задач, требуемое дизайном.

опыт три

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

Если расписание смен обновляется, есть четыре варианта.

Вариант 1: Стремитесь к точности информации о персонале, не принимая во внимание историческую информацию. Удаление персонала IPD, корректировка информации о смене персонала, отсутствие исторической информации.

Вариант 2. Запрос в реальном времени отсутствует, а исторические данные об осадках обрабатываются пакетами. Данные по фазе осаждения остаются противоречивыми.

Вариант 3: Модификация – осадки.

Вариант 4: Сократить цикл осадков и сузить диапазон ошибок данных.

Что лучше, вариант 3 или вариант 4? Зависит от конкретных требований, но когда мы на самом деле это сделаем, мы выберем вариант 4.

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

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

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

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

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

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

Скрыть некритическую информацию. Конфигурация завершена Во время использования на детали обращают внимание только тогда, когда что-то идет не так. Информация о всей цепочке инструментов очень богата, поэтому, если есть ошибка, она будет напомнена и будет предоставлена ​​​​подробная информация.

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

Видное использование, конфигурация разделения. Когда мы переходим к использованию продукта цепочки инструментов, 10% времени уходит на настройку рабочего процесса, а после настройки 90% времени не нужно менять. Если у инструмента есть такая характеристика «используй больше, стань меньше», сосредоточься на той части, которая используется, упрости часть конфигурации, скрой функцию и медленно раздели конфигурацию.

Упрощенная операция. Разработка всей цепочки инструментов 2B призвана решить проблему эффективности. В DevOps есть большая проблема: если каждый билд генерирует версию, а потом на основе этой версии запускается тест, то необходимо проверять статус всего жизненного цикла.

Поэтому нам необходимо наладить систему отслеживания всего процесса.

DevOps не так сложен, как все думают, но и не так прост.

На сегодня это все, всем спасибо!