- Оригинальный адрес:Moving to DevOps: what tools do you really need?
- Оригинальный автор:June Jung
- Перевод с:Программа перевода самородков
- Постоянная ссылка на эту статью:GitHub.com/rare earth/gold-no…
- Переводчик:Starrier
- Корректор:suhanyujie
DevOps — это новейшее решение ряда проблем, для каждой из которых есть библиотека цифровых инструментов: системы CI/CD, фреймворки для тестирования, инструменты мониторинга, инструменты аудита безопасности и т. д. Какие инструменты вам нужны? Какие из них могут решить проблемы, болевые точки вашей организации? Когда я помогаю командам любого размера, я часто слышу два вопроса: «Какая организационная структура нам нужна? Какие инструменты мы должны использовать?»
И то, и другое не проблема, но все просят, не ухватились за ключевые моменты. Когда вы отвечаете на эти вопросы напрямую, вы должны сначала оценить потребности вашей организации для решения проблемы, а затем рассмотреть решение.
Организации часто думают, что нисходящая модель («Используй это! Делай это!») заставит их команды внедрять инновации быстрее. Хороший руководитель группы предлагает новый инструмент CI/CD, который позволяет всем быть занятыми. Когда компетентный руководитель группы внедряет новый инструмент CI/CD, он гарантирует, что он будет запущен и работает у всех. Проблема возникает, когда руководители групп внедряют инструменты, не полностью понимая их ценность и зачем они это делают. Даже люди, которые изначально предлагают изменение, забывают об изначальной цели использования инструмента и ожидаемых выгодах. К сожалению, как только первоначальный замысел забыт, инструмент можно использовать не по назначению, что приведет к различным потерям и отрицательным значениям.
Нам нужен DevOps!
Я встречал множество организаций, которые подтвердили, что DevOps — это решение всех их проблем, если они могут быстро приступить к работе.
Если вы сейчас находитесь в таком положении, спросите себя: «Зачем использовать DevOps в вашей организации? Какую ценность мы хотим, чтобы это нам принесло».
На этом этапе давайте обсудим, что такое DevOps, а не что.
DevOps — это особая схема сотрудничества между командами разработки и эксплуатации. По сути, это показывает, что вы применили культурные методы разработки к своей инфраструктуре и применили методы к своему циклу разработки. Как это работает на практике? Это может означать сохранение инфраструктуры как кода или создание неизменной инфраструктуры путем создания повторно используемых компонентов, которые можно удалять или включать по желанию, обеспечивая контроль версий и историю изменений. Это также означает, что все участники проекта должны быть более сосредоточены на конечном результате своей работы — как они работают? Как пользователи взаимодействуют с ними. Заставить людей заботиться о качестве означает заботиться о его ценности для бизнеса и удобстве использования. Когда каждый, кто создает продукт, в конечном итоге заботится об обоих аспектах качества, о том, что происходит после развертывания, и о том, что происходит, когда он наконец представлен пользователям, именно для этого и нужен DevOps.
По моему опыту, эта широкая поддержка особенно сложна для групп разработчиков программного обеспечения, поскольку требует совместной работы людей с разными навыками и знаниями в предметной области. Для этого требуется как кросс-функциональная командная структура, так и вдумчивые коммуникативные навыки. Например, если человеку со стороны бизнеса нужно обсудить проблему с базой данных на работе, то ему нужно не только сообщить ему данные, с которыми он имеет дело, но и дать необходимую предысторию проблемы и сосредоточить внимание этого человека на что их должно беспокоить и по какой причине.
Следует ли внедрять новые инструменты? Ответ может быть: возможно. Инструменты иногда являются скорее быстрым решением, чем общим решением. По моему опыту, при внедрении новых инструментов DevOpsДо, учитывая эти соображения, вы повысите свои шансы на успех.
Перед началом трансформации:
1. Убедитесь, что все согласны. Все должны согласиться с этим вопросом и согласиться с вашими мыслями о том, чего вы пытаетесь достичь с помощью этого изменения.
2. Начните медленно. Не параноидально превращайте эту организацию в модель DevOps за одну ночь. Вместо этого начните с команды и посмотрите, подходит ли изменение подхода к вашей организации. Если вы видите положительные улучшения, продолжайте улучшаться.
3. Поймите работу, которую вы должны сделать. Поймите, что DevOps может быть неправильным решением проблем вашей организации. Некоторые компании добились успеха без DevOps, что может быть неприменимо к ним, учитывая их культуру и продукт. Я лично считаю, что водопадный рабочий процесс будет более применим к успешным организациям. Например, если конфиденциальность является важной частью продуктовой стратегии вашей компании, то пошаговая поставка для получения отзывов вам не подойдет, потому что вам придется блокировать все сведения о продукте до выпуска, до крупного выпуска. В этом случае создание культуры DevOps может быть чрезвычайно сложным.
4. Гарантированное измерение. Прежде чем приступить к каким-либо инициативам по улучшению, получите индикатор своего текущего состояния (т. е. продолжительность цикла разработки). Пожалуйста, сделайте это, прежде чем приглашать SRE в команду разработчиков. Через некоторое время вы увидите, работает ли он. Измерьте до и после внесения изменений, чтобы увидеть, изменилось ли оно. Например, во время многочисленных agile-трансформаций многие компании внедрили стендапы, толком не понимая, почему и не измеряя, оказало ли это положительное влияние на их команды. Это может привести к потере времени больше, чем сэкономлено.
5. Не все поддается автоматизации. По крайней мере, не сразу сделать переход к полной автоматизации. DevOps ошибочное мнение, что вся инфраструктура и автоматизировать управление конфигурацией должны быть завершены. Их называют «Инфраструктура как код.» Но некоторые вещи вручную эффект будет лучше. Метод не решает все задачи автоматизации. Рассмотрим, вы будете запускать скрипт автоматизации, сколько раз и сколько времени вам нужно автоматизировать. Вы будете часто использовать автоматизированные или только иногда? Иногда, вы должны вручную, или даже выяснить, что лучшие решения в области автоматизации. Тем не менее стремятся автоматизировать? Пусть применение Докер, является отличным решений в области автоматизации, в результате ваших усилий по оплате труда могут быть использованы повторно. Автоматизированная среда подготовки производства является еще одним хорошим способом автоматизировать. Опять же пример, если вы пытались автоматизировать настройки брандмауэра? Учитывая нынешнее отсутствие поддержки API многих программного обеспечения брандмауэра, такие попытки могут быть не стоит. Хотя для аварийного восстановления является настолько значимым, но на самом деле, значение, которое вы получите от этого, это может быть гораздо меньше усилий вы даете.
что дальше?
Если ваша организация рассматривает возможность использования DevOps, в первую очередь подумайте о скорости доставки и качестве продукта. Какова реальная проблема, с которой вы столкнулись сейчас? Знание ответов на эти вопросы поможет всем в вашей организации понять, в чем сейчас болевые точки, чтобы вы могли изменить их в нужном месте.
В будущих статьях я помогу вам с некоторыми практическими боями.Узнайте, что не так с вашей организацией сегодня, чтобы помочь вам повысить уверенность в оценке того, какие инструменты или методы лечения являются оптимальными решениями этих проблем.
Если вы обнаружите ошибки в переводе или в других областях, требующих доработки, добро пожаловать наПрограмма перевода самородковВы также можете получить соответствующие бонусные баллы за доработку перевода и PR. начало статьиПостоянная ссылка на эту статьюЭто ссылка MarkDown этой статьи на GitHub.
Программа перевода самородковэто сообщество, которое переводит высококачественные технические статьи из Интернета сНаггетсДелитесь статьями на английском языке на . Охват контентаAndroid,iOS,внешний интерфейс,задняя часть,блокчейн,продукт,дизайн,искусственный интеллектЕсли вы хотите видеть более качественные переводы, пожалуйста, продолжайте обращать вниманиеПрограмма перевода самородков,официальный Вейбо,Знай колонку.