День пятьсот тридцать четвёртый. #DevOps
Как Убить Производительность Разработчиков. Начало
Немного нестандартная серия постов не совсем про кодинг, а про DevOps. Генеральный директор Humanitec Каспар фон Грюнберг делится некоторыми мыслями о производительности труда разработчиков и о том, как её улучшить.
Убийца №1: Бросить всё ради микросервисов без надлежащего инструментария
Когда команды работают с монолитными приложениями, всё работает хорошо. Цепочка инструментов хорошо подготовлена и справляется с задачей. Но малейшее изменение требует пересборки всего приложения. Необходимо провести сквозные тесты, чтобы убедиться, что всё в порядке. Чем больше монолитное приложение, тем менее эффективным это будет. Команда принимает решение использовать микросервисы. Первый опыт великолепен, коллеги могут работать над отдельными сервисами независимо, частота развёртывания возрастает, и все довольны.
Проблемы начинаются, когда команды увлекаются микросервисами и воспринимают «микро» слишком серьезно. С точки зрения инструментария вам теперь придется иметь дело с гораздо бОльшим количеством yml-файлов, docker-файлов, с зависимостями между переменными этих сервисов, проблемами маршрутизации и т.д. Микросервисы должны поддерживаться, обновляться и обслуживаться. Ваши настройки CI/CD, а также ваша организационная структура и, возможно, численность персонала нуждаются в обновлении.
Если по какой-либо причине вы занимаетесь микросервисами, убедитесь, что у вас достаточно времени для настройки инструментов и реструктуризацию рабочего процесса. Просто посчитайте количество скриптов в разных местах, которые вам нужно поддерживать. Подумайте, сколько времени это займет, кто будет нести ответственность, и какие инструменты могут помочь вам держать всё это под контролем. Если вы выбираете какие-либо новые инструменты, убедитесь, что есть сообщество пользователей, использующих их в микросервисах.
Убийца №2: Использование контейнеров без плана рефакторинга настроек
Контейнерирование - это потрясающая технология для многих ситуаций. Тем не менее, она имеет свою цену и может повлиять на вашу производительность. Контейнеры увеличивают накладные расходы на обеспечение безопасности и необходимую настройку, управление средой и т.д. Они также могут снизить вашу производительность и испортить жизнь разработчикам, если вы не выработаете определённые соглашения в команде.
Самая распространенная ошибка - это встраивание ваших файлов конфигурации или переменных среды в контейнер. Основная идея контейнеризации - мобильность. При жёсткой конфигурации вам придётся писать настройки для каждой отдельной среды. Вы хотите изменить URL? Хорошо, измените его в 20 разных местах, а затем пересоберите проект.
Прежде чем начать использовать контейнеры, соберитесь командой и договоритесь о том, какие соглашения о конфигурации важны для вас. Обязательно последовательно обсуждайте их в обзорах кода и ретроспективных обзорах. Рефакторинг настроек - это априори боль.
Продолжение следует…
Источник: https://dzone.com/articles/how-to-kill-your-developer-productivity-humanitec
Как Убить Производительность Разработчиков. Начало
Немного нестандартная серия постов не совсем про кодинг, а про DevOps. Генеральный директор Humanitec Каспар фон Грюнберг делится некоторыми мыслями о производительности труда разработчиков и о том, как её улучшить.
Убийца №1: Бросить всё ради микросервисов без надлежащего инструментария
Когда команды работают с монолитными приложениями, всё работает хорошо. Цепочка инструментов хорошо подготовлена и справляется с задачей. Но малейшее изменение требует пересборки всего приложения. Необходимо провести сквозные тесты, чтобы убедиться, что всё в порядке. Чем больше монолитное приложение, тем менее эффективным это будет. Команда принимает решение использовать микросервисы. Первый опыт великолепен, коллеги могут работать над отдельными сервисами независимо, частота развёртывания возрастает, и все довольны.
Проблемы начинаются, когда команды увлекаются микросервисами и воспринимают «микро» слишком серьезно. С точки зрения инструментария вам теперь придется иметь дело с гораздо бОльшим количеством yml-файлов, docker-файлов, с зависимостями между переменными этих сервисов, проблемами маршрутизации и т.д. Микросервисы должны поддерживаться, обновляться и обслуживаться. Ваши настройки CI/CD, а также ваша организационная структура и, возможно, численность персонала нуждаются в обновлении.
Если по какой-либо причине вы занимаетесь микросервисами, убедитесь, что у вас достаточно времени для настройки инструментов и реструктуризацию рабочего процесса. Просто посчитайте количество скриптов в разных местах, которые вам нужно поддерживать. Подумайте, сколько времени это займет, кто будет нести ответственность, и какие инструменты могут помочь вам держать всё это под контролем. Если вы выбираете какие-либо новые инструменты, убедитесь, что есть сообщество пользователей, использующих их в микросервисах.
Убийца №2: Использование контейнеров без плана рефакторинга настроек
Контейнерирование - это потрясающая технология для многих ситуаций. Тем не менее, она имеет свою цену и может повлиять на вашу производительность. Контейнеры увеличивают накладные расходы на обеспечение безопасности и необходимую настройку, управление средой и т.д. Они также могут снизить вашу производительность и испортить жизнь разработчикам, если вы не выработаете определённые соглашения в команде.
Самая распространенная ошибка - это встраивание ваших файлов конфигурации или переменных среды в контейнер. Основная идея контейнеризации - мобильность. При жёсткой конфигурации вам придётся писать настройки для каждой отдельной среды. Вы хотите изменить URL? Хорошо, измените его в 20 разных местах, а затем пересоберите проект.
Прежде чем начать использовать контейнеры, соберитесь командой и договоритесь о том, какие соглашения о конфигурации важны для вас. Обязательно последовательно обсуждайте их в обзорах кода и ретроспективных обзорах. Рефакторинг настроек - это априори боль.
Продолжение следует…
Источник: https://dzone.com/articles/how-to-kill-your-developer-productivity-humanitec
День пятьсот тридцать пятый. #DevOps
Как Убить Производительность Разработчиков. Продолжение
Убийца №3: Неправильное Использование Kubernetes
Все крутые ребята расхваливают Kubernetes. Тем не менее, его трудно поддерживать и трудно интегрировать в ваш поток разработки, сохраняя при этом высокую производительность. Многое может пойти не так.
Худший случай использования Kubernetes: Коллега X очень хотел его попробовать и нашёл руководство для начинающих онлайн. Они создали кластер с нуля, и он отлично работал с тестовым приложением. Затем они начали миграцию первого приложения и попросили своих коллег начать взаимодействие с кластером с помощью kubectl. Половина команды теперь была занята изучением этой новой технологии. Человек, который обслуживает кластер, теперь будет занят этим постоянно, как только кластер получит первую рабочую нагрузку. Конфигурация CI/CD совершенно не подготовлена для решения этой проблемы, и общая производительность снижается, поскольку вся команда пытается сбалансировать Kubernetes.
Kubernetes - это потрясающая технология, которая, если все сделано правильно, может вам помочь. В конце концов, она исходит от Borg - платформы, созданной Google, чтобы их разработчикам было легче создавать масштабируемые приложения. Таким образом, это своего рода интерпретация внутренней платформы Google.
Лучшие практики:
1. Там, где это возможно, команды не должны сами устанавливать и запускать barebone кластер, а должны использовать управляемую службу Kubernetes. Прочитайте отзывы о том, какой управляемый кластер Kubernetes лучше всего соответствует вашим потребностям. На данный момент Google Kubernetes Engine (GKE) является лучшим с чисто технической точки зрения. За ним следуют службы Azure Kubernetes (AKS) и Amazon Elastic Kubernetes Service.
2. Используйте платформы автоматизации или API непрерывной доставки. Они позволяют запускать вашу рабочую нагрузку на K8 вне поля зрения разработчиков. Практически не имеет смысла посвящать всех в сложности процесса конфигурации.
3. Если команда действительно хочет, чтобы разработчики сами управляли кластером Kubernetes, нужно дать им достаточно времени, чтобы по-настоящему понять архитектуру, шаблоны проектирования, kubectl и т.д. и действительно сосредоточиться на этом.
Убийца №4: Игнорирование постоянной доставки
Существует распространенное заблуждение, что работа выполнена хорошо, если настроена непрерывная интеграция. Но вам всё ещё не хватает непрерывной доставки! Многие из тех, кто использует термин «инструмент CI/CD» думают, что добились непрерывной доставки, если у них есть Jenkins, CircleCI и т.д. Но это не так.
Тщательная настройка Continuous Delivery, с использованием собственных сценариев или «как услуга», является гораздо более важным «связующим звеном»:
1. Она позволяет интегрировать все различные компоненты, от системы управления исходным кодом до CI-Pipeline, от базы данных до кластера и от настройки DNS до IaC, в удобную среду для разработчиков.
2. Это способ структурировать, поддерживать и управлять растущим количеством сценариев yml и конфигурации. Если всё сделано правильно, это позволит вашим разработчикам динамически разворачивать среды с помощью артефактов, созданных CI-Pipeline с полной настройкой и подготовкой базы данных.
3. Она может выступать в качестве системы контроля версий для состояний конфигурации с подтверждённой записью о том, что, где, в какой конфигурации развернуто, и позволяет выполнять откат назад и вперед, а также управлять развёртываниями.
4. Хорошо продуманные настройки CD оказывают кардинальное влияние на производительность труда разработчиков. Они делают разработчиков самодостаточными, уменьшают количество зависимостей в команде, повышая удобство обслуживания вашей конфигурации.
5. Команды, использующие эти методы, делают релизы чаще, быстрее, демонстрируют в целом более высокую производительность и удовлетворённость от работы.
Окончание следует…
Источник: https://dzone.com/articles/how-to-kill-your-developer-productivity-humanitec
Как Убить Производительность Разработчиков. Продолжение
Убийца №3: Неправильное Использование Kubernetes
Все крутые ребята расхваливают Kubernetes. Тем не менее, его трудно поддерживать и трудно интегрировать в ваш поток разработки, сохраняя при этом высокую производительность. Многое может пойти не так.
Худший случай использования Kubernetes: Коллега X очень хотел его попробовать и нашёл руководство для начинающих онлайн. Они создали кластер с нуля, и он отлично работал с тестовым приложением. Затем они начали миграцию первого приложения и попросили своих коллег начать взаимодействие с кластером с помощью kubectl. Половина команды теперь была занята изучением этой новой технологии. Человек, который обслуживает кластер, теперь будет занят этим постоянно, как только кластер получит первую рабочую нагрузку. Конфигурация CI/CD совершенно не подготовлена для решения этой проблемы, и общая производительность снижается, поскольку вся команда пытается сбалансировать Kubernetes.
Kubernetes - это потрясающая технология, которая, если все сделано правильно, может вам помочь. В конце концов, она исходит от Borg - платформы, созданной Google, чтобы их разработчикам было легче создавать масштабируемые приложения. Таким образом, это своего рода интерпретация внутренней платформы Google.
Лучшие практики:
1. Там, где это возможно, команды не должны сами устанавливать и запускать barebone кластер, а должны использовать управляемую службу Kubernetes. Прочитайте отзывы о том, какой управляемый кластер Kubernetes лучше всего соответствует вашим потребностям. На данный момент Google Kubernetes Engine (GKE) является лучшим с чисто технической точки зрения. За ним следуют службы Azure Kubernetes (AKS) и Amazon Elastic Kubernetes Service.
2. Используйте платформы автоматизации или API непрерывной доставки. Они позволяют запускать вашу рабочую нагрузку на K8 вне поля зрения разработчиков. Практически не имеет смысла посвящать всех в сложности процесса конфигурации.
3. Если команда действительно хочет, чтобы разработчики сами управляли кластером Kubernetes, нужно дать им достаточно времени, чтобы по-настоящему понять архитектуру, шаблоны проектирования, kubectl и т.д. и действительно сосредоточиться на этом.
Убийца №4: Игнорирование постоянной доставки
Существует распространенное заблуждение, что работа выполнена хорошо, если настроена непрерывная интеграция. Но вам всё ещё не хватает непрерывной доставки! Многие из тех, кто использует термин «инструмент CI/CD» думают, что добились непрерывной доставки, если у них есть Jenkins, CircleCI и т.д. Но это не так.
Тщательная настройка Continuous Delivery, с использованием собственных сценариев или «как услуга», является гораздо более важным «связующим звеном»:
1. Она позволяет интегрировать все различные компоненты, от системы управления исходным кодом до CI-Pipeline, от базы данных до кластера и от настройки DNS до IaC, в удобную среду для разработчиков.
2. Это способ структурировать, поддерживать и управлять растущим количеством сценариев yml и конфигурации. Если всё сделано правильно, это позволит вашим разработчикам динамически разворачивать среды с помощью артефактов, созданных CI-Pipeline с полной настройкой и подготовкой базы данных.
3. Она может выступать в качестве системы контроля версий для состояний конфигурации с подтверждённой записью о том, что, где, в какой конфигурации развернуто, и позволяет выполнять откат назад и вперед, а также управлять развёртываниями.
4. Хорошо продуманные настройки CD оказывают кардинальное влияние на производительность труда разработчиков. Они делают разработчиков самодостаточными, уменьшают количество зависимостей в команде, повышая удобство обслуживания вашей конфигурации.
5. Команды, использующие эти методы, делают релизы чаще, быстрее, демонстрируют в целом более высокую производительность и удовлетворённость от работы.
Окончание следует…
Источник: https://dzone.com/articles/how-to-kill-your-developer-productivity-humanitec
День пятьсот тридцать шестой. #DevOps
Как Убить Производительность Разработчиков. Окончание
Убийца №5: Неуправляемая автоматизация тестирования в ограниченной конфигурации тестов
Эффективное тестирование невозможно без автоматизации. С непрерывной доставкой приходит непрерывная ответственность, чтобы ничего не сломать.
Вы должны постоянно следить за тем, чтобы не попасть в ловушку инвертирования тестовой пирамиды. Для этого вам нужно иметь возможность запускать правильные тесты в нужной точке жизненного цикла разработки.
Достаточный инструментарий CI поможет вам правильно разместить модульные и интеграционные тесты в нужном месте, а инструментарий CD с управлением конфигурацией и средой поможет вам надёжно выполнять автоматизированные сквозные тесты.
Хорошо выполненные настройки позволяют разработчикам или тестировщикам динамически разворачивать предварительно настроенные среды. Строго экспортируйте вашу конфигурацию и убедитесь, что у вас есть система управления конфигурацией, позволяющая использовать нужные параметры при развёртывании. Это приводит к ряду улучшений:
- Выполнению правильных тестов в нужное время, обеспечивая эффективную обратную связь с командой разработчиков.
- Разработчики получат автономию, а вы уменьшите зависимость от ключевых людей.
- QA смогут выполнять подмножества тестов в функциональных средах, а также распараллеливать тестирование.
Убийца №6: Самостоятельное управление базами данных
Товарищ по команде, который только что ушел, отвечал за настройку MongoDB для клиентского проекта и, конечно, использовал проект с открытым исходным кодом, в котором размещалась база. И, естественно, передача дел была «безупречной», база данных не была должным образом защищена, и однажды вечером случилось то, что должно было: «Ваша база данных была сохранена и архивирована. У вас есть 7 дней, чтобы её восстановить. Пришлите 0.1 BTC …»
И конечно:
- Вы проверяете резервные копии.
- В коде резервного копирования обнаружилась ошибка.
- Теперь вам нужно восстанавливать все данные.
Это реальный пример, который часто случается. Самоуправляемые БД представляют собой операционный риск и угрозу безопасности. Используйте Cloud SQL или другие предложения и спите спокойно. Эти сервисы предлагают большинство баз данных на всех крупных облачных провайдерах, и они являются более многофункциональными, зрелыми и защищёнными. Кроме того, они часто дешевле и доставляют минимум неудобств для разработчика.
Убийца №7: Использование нескольких облаков без причины
Есть разница между переходом на несколько облаков и попыткой сделать ваши системы независимыми от облачных вычислений и переносимыми. Последнее имеет много различных преимуществ, таких как динамические среды, и имеет больше смысла, чем переход на несколько облаков. Конечно, есть наследие: одни команды использовали GCP, другой отдел начал с AWS, а третьим нужны специальные условия - и вуаля. Можно спорить, что одни сервисы работают лучше или дешевле, чем другие. Но чтобы эти эффекты действительно имели значение, вам нужен достаточный объём. Несложные многооблачные установки требуют высокой степени автоматизации и защиты разработчиков от задач их настройки и поддержки. В противном случае человек попадает в ад сценариев.
Как правило: не используйте несколько облаков, если в этом нет необходимости.
Итого
«1% лучших команд делают релизы в 10 раз чаще остальных». Это потому, что они используют большую часть того, что им доступно. Остановитесь и проведите полдня в месяц, пересматривая свои рабочие процессы, списки дел и способы организации своих приложений, чтобы обеспечить оптимальную производительность. Потому что потраченное время действительно накапливается. Крошечные проблемы загружают ваш мозг. Пересмотр ваших процессов поможет вам сосредоточиться на деле, а не на настройке, и сделает вас и вашу команду счастливее.
Источник: https://dzone.com/articles/how-to-kill-your-developer-productivity-humanitec
Как Убить Производительность Разработчиков. Окончание
Убийца №5: Неуправляемая автоматизация тестирования в ограниченной конфигурации тестов
Эффективное тестирование невозможно без автоматизации. С непрерывной доставкой приходит непрерывная ответственность, чтобы ничего не сломать.
Вы должны постоянно следить за тем, чтобы не попасть в ловушку инвертирования тестовой пирамиды. Для этого вам нужно иметь возможность запускать правильные тесты в нужной точке жизненного цикла разработки.
Достаточный инструментарий CI поможет вам правильно разместить модульные и интеграционные тесты в нужном месте, а инструментарий CD с управлением конфигурацией и средой поможет вам надёжно выполнять автоматизированные сквозные тесты.
Хорошо выполненные настройки позволяют разработчикам или тестировщикам динамически разворачивать предварительно настроенные среды. Строго экспортируйте вашу конфигурацию и убедитесь, что у вас есть система управления конфигурацией, позволяющая использовать нужные параметры при развёртывании. Это приводит к ряду улучшений:
- Выполнению правильных тестов в нужное время, обеспечивая эффективную обратную связь с командой разработчиков.
- Разработчики получат автономию, а вы уменьшите зависимость от ключевых людей.
- QA смогут выполнять подмножества тестов в функциональных средах, а также распараллеливать тестирование.
Убийца №6: Самостоятельное управление базами данных
Товарищ по команде, который только что ушел, отвечал за настройку MongoDB для клиентского проекта и, конечно, использовал проект с открытым исходным кодом, в котором размещалась база. И, естественно, передача дел была «безупречной», база данных не была должным образом защищена, и однажды вечером случилось то, что должно было: «Ваша база данных была сохранена и архивирована. У вас есть 7 дней, чтобы её восстановить. Пришлите 0.1 BTC …»
И конечно:
- Вы проверяете резервные копии.
- В коде резервного копирования обнаружилась ошибка.
- Теперь вам нужно восстанавливать все данные.
Это реальный пример, который часто случается. Самоуправляемые БД представляют собой операционный риск и угрозу безопасности. Используйте Cloud SQL или другие предложения и спите спокойно. Эти сервисы предлагают большинство баз данных на всех крупных облачных провайдерах, и они являются более многофункциональными, зрелыми и защищёнными. Кроме того, они часто дешевле и доставляют минимум неудобств для разработчика.
Убийца №7: Использование нескольких облаков без причины
Есть разница между переходом на несколько облаков и попыткой сделать ваши системы независимыми от облачных вычислений и переносимыми. Последнее имеет много различных преимуществ, таких как динамические среды, и имеет больше смысла, чем переход на несколько облаков. Конечно, есть наследие: одни команды использовали GCP, другой отдел начал с AWS, а третьим нужны специальные условия - и вуаля. Можно спорить, что одни сервисы работают лучше или дешевле, чем другие. Но чтобы эти эффекты действительно имели значение, вам нужен достаточный объём. Несложные многооблачные установки требуют высокой степени автоматизации и защиты разработчиков от задач их настройки и поддержки. В противном случае человек попадает в ад сценариев.
Как правило: не используйте несколько облаков, если в этом нет необходимости.
Итого
«1% лучших команд делают релизы в 10 раз чаще остальных». Это потому, что они используют большую часть того, что им доступно. Остановитесь и проведите полдня в месяц, пересматривая свои рабочие процессы, списки дел и способы организации своих приложений, чтобы обеспечить оптимальную производительность. Потому что потраченное время действительно накапливается. Крошечные проблемы загружают ваш мозг. Пересмотр ваших процессов поможет вам сосредоточиться на деле, а не на настройке, и сделает вас и вашу команду счастливее.
Источник: https://dzone.com/articles/how-to-kill-your-developer-productivity-humanitec
День 1318. #DevOps
6 Принципов Разработки Архитектуры ПО
В последнее время термин «непрерывный» (continuous) очень часто используется в речи поставщиков ПО и экспертов как программная архитектура, которую мы все должны и хотим иметь. Проблема в том, что многие считают, что «непрерывный» означает быструю доставку. Однако проектирование непрерывной программной архитектуры требует постоянной обратной связи от всех участников процесса: архитекторов, дизайнеров, разработчиков, операторов — и постоянного улучшения. Разработка архитектуры ПО больше не может быть разовым процессом.
Об этом на недавней конференции GOTO 2022 поговорили Пьер Пюрер, соавтор книги «Continuous Architecture in Practice», и Курт Биттнер, глава отдела корпоративных решений в Scrum.org.
«Проектирование и поддержка хорошо функционирующей непрерывной программной архитектуры требует, прежде всего, терпения,» - считает Пюрер. - «Cпешить с технологическим решением, прежде чем задать правильные вопросы, означает упускать возможности или функции, которые могут быть жизненно важными для бизнеса. Я видел команды, которые начинают с конца, и они знают, что хотят внедрить какую-то технологию. Кто-то сказал им: «Нам нужно быть в облаке Amazon». Ответом будет облако Amazon, а вы даже не задаёте этот вопрос.»
В течение многих лет проектирование архитектуры ПО означало проектирование чего-либо на начальном этапе, а затем переход к этапу развёртывания. Согласно традиционному представлению об архитектуре, «мы не пишем ни строчки кода, пока вся архитектура не будет собрана», — сказал Пюрер.
«Проблема с таким подходом, конечно, в том, что очень сложно знать всё сразу. Проектирование архитектуры, когда более половины ваших требований неверны, не даст вам хороших результатов. Трудно предсказать, как система будет эволюционировать."
Появились более гибкие подходы, что сделало процесс более итеративным. Тем не менее, это предполагает, что «вы пишете код, и архитектура каким-то образом появляется, как кит из воды». Но это приводит к необходимости «большого рефакторинга и перенастройки».
Гибкая разработка — это шаг в правильном направлении, но для непрерывной архитектуры проектировщики и разработчики ПО должны сделать ещё один шаг.
Им нужно задавать трудные вопросы: что нужно бизнесу? Что лучше сработает для пользователей или клиентов? Какие части бизнеса должны быть вовлечены в процесс проектирования?
По словам Пюрера, в основе успешной непрерывной архитектуры лежат шесть принципов. «Ни один из принципов не является новым или революционным, но вместе они имеют большой смысл».
Вот эти принципы:
1. Создавайте архитектуру продукта, а не проекта. Звучит очевидно, но многие об этом забывают.
2. Сосредоточьтесь на атрибутах качества, а не на обширности функционала. Да, функциональные требования важны, но, если качество не соответствует, у вас не получится эффективного продукта.
3. Откладывайте решения до тех пор, пока не будете уверены, что должны принять решение. У каждого решения есть цена. А если оно окажется неверным, будет и цена отката этого решения. Не принимайте решения слишком рано, пытаясь угадать, старайтесь основывать решение на фактах.
4. Планируйте изменения, потому что всё изменится — так что подумайте о «минималистичном дизайне». Хотя это не обязательно означает микросервисы.
5. Помните, тестирование сборки системы важно, но тестирование развёртывания системы едва ли не важнее.
6. Организуйте команду из людей, которые занимаются всеми аспектами системы. Да, может быть разделение на фронт и бэк, но все специалисты должны чётко представлять, какой продукт должен получиться.
«Люди думают об архитектуре как о чертежах, красивых диаграммах и т. д.», — говорит Пюрер. - «Да, у вас должны быть эти вещи, с помощью которых вы будете общаться, как часть архитектуры. Поскольку вы постоянно принимаете решения, вы будете учиться на своих ошибках, постоянно возвращаться и пересматривать свои решения».
Источник: https://www.zdnet.com/article/agile-alertness-6-principles-to-help-your-software-design-process-succeed/
6 Принципов Разработки Архитектуры ПО
В последнее время термин «непрерывный» (continuous) очень часто используется в речи поставщиков ПО и экспертов как программная архитектура, которую мы все должны и хотим иметь. Проблема в том, что многие считают, что «непрерывный» означает быструю доставку. Однако проектирование непрерывной программной архитектуры требует постоянной обратной связи от всех участников процесса: архитекторов, дизайнеров, разработчиков, операторов — и постоянного улучшения. Разработка архитектуры ПО больше не может быть разовым процессом.
Об этом на недавней конференции GOTO 2022 поговорили Пьер Пюрер, соавтор книги «Continuous Architecture in Practice», и Курт Биттнер, глава отдела корпоративных решений в Scrum.org.
«Проектирование и поддержка хорошо функционирующей непрерывной программной архитектуры требует, прежде всего, терпения,» - считает Пюрер. - «Cпешить с технологическим решением, прежде чем задать правильные вопросы, означает упускать возможности или функции, которые могут быть жизненно важными для бизнеса. Я видел команды, которые начинают с конца, и они знают, что хотят внедрить какую-то технологию. Кто-то сказал им: «Нам нужно быть в облаке Amazon». Ответом будет облако Amazon, а вы даже не задаёте этот вопрос.»
В течение многих лет проектирование архитектуры ПО означало проектирование чего-либо на начальном этапе, а затем переход к этапу развёртывания. Согласно традиционному представлению об архитектуре, «мы не пишем ни строчки кода, пока вся архитектура не будет собрана», — сказал Пюрер.
«Проблема с таким подходом, конечно, в том, что очень сложно знать всё сразу. Проектирование архитектуры, когда более половины ваших требований неверны, не даст вам хороших результатов. Трудно предсказать, как система будет эволюционировать."
Появились более гибкие подходы, что сделало процесс более итеративным. Тем не менее, это предполагает, что «вы пишете код, и архитектура каким-то образом появляется, как кит из воды». Но это приводит к необходимости «большого рефакторинга и перенастройки».
Гибкая разработка — это шаг в правильном направлении, но для непрерывной архитектуры проектировщики и разработчики ПО должны сделать ещё один шаг.
Им нужно задавать трудные вопросы: что нужно бизнесу? Что лучше сработает для пользователей или клиентов? Какие части бизнеса должны быть вовлечены в процесс проектирования?
По словам Пюрера, в основе успешной непрерывной архитектуры лежат шесть принципов. «Ни один из принципов не является новым или революционным, но вместе они имеют большой смысл».
Вот эти принципы:
1. Создавайте архитектуру продукта, а не проекта. Звучит очевидно, но многие об этом забывают.
2. Сосредоточьтесь на атрибутах качества, а не на обширности функционала. Да, функциональные требования важны, но, если качество не соответствует, у вас не получится эффективного продукта.
3. Откладывайте решения до тех пор, пока не будете уверены, что должны принять решение. У каждого решения есть цена. А если оно окажется неверным, будет и цена отката этого решения. Не принимайте решения слишком рано, пытаясь угадать, старайтесь основывать решение на фактах.
4. Планируйте изменения, потому что всё изменится — так что подумайте о «минималистичном дизайне». Хотя это не обязательно означает микросервисы.
5. Помните, тестирование сборки системы важно, но тестирование развёртывания системы едва ли не важнее.
6. Организуйте команду из людей, которые занимаются всеми аспектами системы. Да, может быть разделение на фронт и бэк, но все специалисты должны чётко представлять, какой продукт должен получиться.
«Люди думают об архитектуре как о чертежах, красивых диаграммах и т. д.», — говорит Пюрер. - «Да, у вас должны быть эти вещи, с помощью которых вы будете общаться, как часть архитектуры. Поскольку вы постоянно принимаете решения, вы будете учиться на своих ошибках, постоянно возвращаться и пересматривать свои решения».
Источник: https://www.zdnet.com/article/agile-alertness-6-principles-to-help-your-software-design-process-succeed/
👍10
День 1372. #DevOps
Принципы, Реализации и Культура DevOps. Начало
Когда организации начинают использовать DevOps для разработки приложений, многие понимают DevOps только как часть инфраструктуры развёртывания и выбирают подмножество DevOps, вместо того чтобы понять культуру и технологические изменения, необходимые для успеха. Организации должны сначала определить, какой подход «Ops» лучше всего им подходит и интегрировать его в свои рабочие процессы. При этом они будут лучше координировать группы разработки и поддержки относительно общих целей и протоколов.
Существует множество вариаций и поджанров DevOps. Тем не менее, важно, чтобы организации понимали доступные варианты и выбирали тот, который им подходит.
Вариации DevOps
1. DevOps: улучшение технических процессов и культуры
DevOps — это общий термин для операций, которые сочетают концепции Agile-разработки с ИТ-операциями и ускоряют разработку и развёртывание приложений в облачных средах. Хотя существуют разные поджанры DevOps, каждый поджанр представляет собой отдельное приложение методологии DevOps, направленное на то, чтобы сделать разработку более гибкой, стабильной и эффективной. Поскольку DevOps значительно сокращает жизненный цикл разработки, этот оптимизированный подход к разработке приложений довольно популярен.
2. DevSecOps: добавление проверок безопасности
DevSecOps внедряет в рабочий процесс дополнительные меры безопасности. Если в DevOps обычно проводят проверки безопасности в конце цикла, специалисты, использующие DevSecOps, интегрируют средства безопасности на раннем этапе. В DevSecOps сотрудничество между разработчиками, специалистами по безопасности и поддержкой имеет решающее значение для поддержания гибкости и скорости доставки, но дополнительные уровни безопасности могут замедлить процессы. DevSecOps использует быстрое тестирование и надёжные конвейеры для повышения целостности кода. Этот метод может быть полезен, если организации необходимо повысить безопасность во время разработки.
3. NoOps: сокращение внутренних команд для операций
NoOps — это возвышенный взгляд на DevOps. Ощущение, что он настолько автоматизирован, что не требует отдельных специалистов внутри компании, а это означает, что ручное вмешательство в процессы не требуется. NoOps отличается от DevOps тем, что меньше внимания уделяется Agile и управлению процессами. Этот процесс предполагает, что разработчикам не нужно знать, как использовать автоматизированные инструменты, и использует методы непрерывной интеграции, позволяющие разработчикам сосредоточиться только на разработке приложений.
Хотя NoOps ускоряет процессы развёртывания, сам по себе он не подразумевает открытого общения между командами и менеджмента команд. Успешное внедрение NoOps возможно только в том случае, если команда разработчиков небольшая, но сильная и способна справиться с разработкой и поддержкой.
4. GitOps: использование Git для автоматизации
GitOps набирает обороты в индустрии разработки благодаря использованию Git для автоматизации конвейеров непрерывной доставки. GitOps — это надёжная и управляемая форма операций, поскольку она использует Git как единственный источник достоверной информации для операций. Кроме того, благодаря тому, что разработчики хорошо знакомы с Git и пулл-реквестами, нет сложного инструмента для изучения, а изменения в существующих рабочих процессах часто не нужны.
Метод GitOps также может похвастаться тем, что он поддерживается одними из самых инновационных облачных сервисов на рынке, что позволяет автоматизировать процесс создания обновления, тестирования на наличие ошибок, проверки кода и отправки обновления в производство. Поскольку Git — единственный источник достоверной информации о GitOps, крайне важно эффективно защитить репозиторий Git, чтобы избежать ненужных коммитов или пулл-реквестов.
Окончание следует…
Источник: https://devops.com/devops-principles-implementations-and-culture/
Принципы, Реализации и Культура DevOps. Начало
Когда организации начинают использовать DevOps для разработки приложений, многие понимают DevOps только как часть инфраструктуры развёртывания и выбирают подмножество DevOps, вместо того чтобы понять культуру и технологические изменения, необходимые для успеха. Организации должны сначала определить, какой подход «Ops» лучше всего им подходит и интегрировать его в свои рабочие процессы. При этом они будут лучше координировать группы разработки и поддержки относительно общих целей и протоколов.
Существует множество вариаций и поджанров DevOps. Тем не менее, важно, чтобы организации понимали доступные варианты и выбирали тот, который им подходит.
Вариации DevOps
1. DevOps: улучшение технических процессов и культуры
DevOps — это общий термин для операций, которые сочетают концепции Agile-разработки с ИТ-операциями и ускоряют разработку и развёртывание приложений в облачных средах. Хотя существуют разные поджанры DevOps, каждый поджанр представляет собой отдельное приложение методологии DevOps, направленное на то, чтобы сделать разработку более гибкой, стабильной и эффективной. Поскольку DevOps значительно сокращает жизненный цикл разработки, этот оптимизированный подход к разработке приложений довольно популярен.
2. DevSecOps: добавление проверок безопасности
DevSecOps внедряет в рабочий процесс дополнительные меры безопасности. Если в DevOps обычно проводят проверки безопасности в конце цикла, специалисты, использующие DevSecOps, интегрируют средства безопасности на раннем этапе. В DevSecOps сотрудничество между разработчиками, специалистами по безопасности и поддержкой имеет решающее значение для поддержания гибкости и скорости доставки, но дополнительные уровни безопасности могут замедлить процессы. DevSecOps использует быстрое тестирование и надёжные конвейеры для повышения целостности кода. Этот метод может быть полезен, если организации необходимо повысить безопасность во время разработки.
3. NoOps: сокращение внутренних команд для операций
NoOps — это возвышенный взгляд на DevOps. Ощущение, что он настолько автоматизирован, что не требует отдельных специалистов внутри компании, а это означает, что ручное вмешательство в процессы не требуется. NoOps отличается от DevOps тем, что меньше внимания уделяется Agile и управлению процессами. Этот процесс предполагает, что разработчикам не нужно знать, как использовать автоматизированные инструменты, и использует методы непрерывной интеграции, позволяющие разработчикам сосредоточиться только на разработке приложений.
Хотя NoOps ускоряет процессы развёртывания, сам по себе он не подразумевает открытого общения между командами и менеджмента команд. Успешное внедрение NoOps возможно только в том случае, если команда разработчиков небольшая, но сильная и способна справиться с разработкой и поддержкой.
4. GitOps: использование Git для автоматизации
GitOps набирает обороты в индустрии разработки благодаря использованию Git для автоматизации конвейеров непрерывной доставки. GitOps — это надёжная и управляемая форма операций, поскольку она использует Git как единственный источник достоверной информации для операций. Кроме того, благодаря тому, что разработчики хорошо знакомы с Git и пулл-реквестами, нет сложного инструмента для изучения, а изменения в существующих рабочих процессах часто не нужны.
Метод GitOps также может похвастаться тем, что он поддерживается одними из самых инновационных облачных сервисов на рынке, что позволяет автоматизировать процесс создания обновления, тестирования на наличие ошибок, проверки кода и отправки обновления в производство. Поскольку Git — единственный источник достоверной информации о GitOps, крайне важно эффективно защитить репозиторий Git, чтобы избежать ненужных коммитов или пулл-реквестов.
Окончание следует…
Источник: https://devops.com/devops-principles-implementations-and-culture/
👍13
День 1373. #DevOps
Принципы, Реализации и Культура DevOps. Окончание
Начало
5. CloudOps: реализация облачных функций
CloudOps пытается получить больше преимуществ от облачных функций, предлагаемых современными провайдерами. Поскольку CloudOps фокусируется на распределённой разработке и развёртывании, отсутствует единая точка отказа, что делает всю облачную среду более надёжной. Кроме того, некоторые части рабочего процесса в этом типе операций могут проходить без сохранения состояния, что делает его экономически эффективным, поскольку организации платят только за те ресурсы, которые они фактически используют. Несмотря на то, что CloudOps может быть эффективным с точки зрения времени и затрат, чрезвычайно важна правильная настройка конфигурации, чтобы этот подход был рабочим, что может означать дополнительные сложности при настройке конвейеров CI/CD.
6. CIOps: операции непрерывной интеграции
Эта последняя итерация DevOps, требующая настройки инфраструктуры, необходимой для поддержки нового кода, перед развёртыванием. Ручной ввод, необходимый для обеспечения правильной конфигурации заданий CI и места развёртывания, имеет как преимущества, так и недостатки. Контроль над инфраструктурой позволяет двум развёртываниям иметь разные конфигурации инфраструктуры. Основные недостатки заключаются в том, что требуемое ручное вмешательство оставляет место для ошибки, а необходимость привязки инструмента CI может представлять угрозу безопасности.
CIOps лучше подходит для небольших сред разработки, где автоматизация доставляет неудобства. Хотя CIOps даёт разработчикам гибкость в настройке облачных инфраструктур, этот подход требует времени и усилий для бесперебойной работы.
7. ITOps: автоматизация конвейеров управления ИТ
ИТ в общих чертах определяется как управление системами, обслуживающими конечных пользователей или сотрудников. Эти системы необходимы для ведения основного бизнеса. Принципиальная разница в том, что разработки тут практически нет. Если вашему бизнесу не требуется команда инженеров-программистов, и вы можете работать исключительно с готовыми приложениями, тогда ITOps для вас.
ITOps отвечает за предоставление и поддержку услуг, приложений и базовых технологий, необходимых для ведения бизнеса, включая такие должности, как системный администратор и сетевой администратор. ITOps фокусируется на обновлении ноутбуков и офисных сетей в дополнение к проверенному коммерческому ПО и решениям для построения инфраструктуры, что усложняет обновление компонентов инфраструктуры. При использовании ITOps ИТ-директор организации сосредоточится на управлении системой посредством автоматизации.
Выбор лучшей операции для организации
Выбор между вариантами DevOps — это вопрос поиска варианта, который лучше всего подходит для приложений, которые разрабатывает организация, и используемой ими облачной инфраструктуры. Хотя все вышеперечисленные стратегии Ops основаны на уникальных идеях, они, как правило, сосредоточены на технической стороне. DevOps же выделяется своей способностью всесторонне улучшать рабочие процессы и оптимизировать технические процессы, одновременно способствуя развитию культуры инноваций и сотрудничества в организации.
Источник: https://devops.com/devops-principles-implementations-and-culture/
Принципы, Реализации и Культура DevOps. Окончание
Начало
5. CloudOps: реализация облачных функций
CloudOps пытается получить больше преимуществ от облачных функций, предлагаемых современными провайдерами. Поскольку CloudOps фокусируется на распределённой разработке и развёртывании, отсутствует единая точка отказа, что делает всю облачную среду более надёжной. Кроме того, некоторые части рабочего процесса в этом типе операций могут проходить без сохранения состояния, что делает его экономически эффективным, поскольку организации платят только за те ресурсы, которые они фактически используют. Несмотря на то, что CloudOps может быть эффективным с точки зрения времени и затрат, чрезвычайно важна правильная настройка конфигурации, чтобы этот подход был рабочим, что может означать дополнительные сложности при настройке конвейеров CI/CD.
6. CIOps: операции непрерывной интеграции
Эта последняя итерация DevOps, требующая настройки инфраструктуры, необходимой для поддержки нового кода, перед развёртыванием. Ручной ввод, необходимый для обеспечения правильной конфигурации заданий CI и места развёртывания, имеет как преимущества, так и недостатки. Контроль над инфраструктурой позволяет двум развёртываниям иметь разные конфигурации инфраструктуры. Основные недостатки заключаются в том, что требуемое ручное вмешательство оставляет место для ошибки, а необходимость привязки инструмента CI может представлять угрозу безопасности.
CIOps лучше подходит для небольших сред разработки, где автоматизация доставляет неудобства. Хотя CIOps даёт разработчикам гибкость в настройке облачных инфраструктур, этот подход требует времени и усилий для бесперебойной работы.
7. ITOps: автоматизация конвейеров управления ИТ
ИТ в общих чертах определяется как управление системами, обслуживающими конечных пользователей или сотрудников. Эти системы необходимы для ведения основного бизнеса. Принципиальная разница в том, что разработки тут практически нет. Если вашему бизнесу не требуется команда инженеров-программистов, и вы можете работать исключительно с готовыми приложениями, тогда ITOps для вас.
ITOps отвечает за предоставление и поддержку услуг, приложений и базовых технологий, необходимых для ведения бизнеса, включая такие должности, как системный администратор и сетевой администратор. ITOps фокусируется на обновлении ноутбуков и офисных сетей в дополнение к проверенному коммерческому ПО и решениям для построения инфраструктуры, что усложняет обновление компонентов инфраструктуры. При использовании ITOps ИТ-директор организации сосредоточится на управлении системой посредством автоматизации.
Выбор лучшей операции для организации
Выбор между вариантами DevOps — это вопрос поиска варианта, который лучше всего подходит для приложений, которые разрабатывает организация, и используемой ими облачной инфраструктуры. Хотя все вышеперечисленные стратегии Ops основаны на уникальных идеях, они, как правило, сосредоточены на технической стороне. DevOps же выделяется своей способностью всесторонне улучшать рабочие процессы и оптимизировать технические процессы, одновременно способствуя развитию культуры инноваций и сотрудничества в организации.
Источник: https://devops.com/devops-principles-implementations-and-culture/
👍5
День 1574. #DevOps #ProjectManagement
Без Паники! Пособие по Управлению Любым Инцидентом в Продакшене. Начало
Независимо от того, насколько сильна ваша организация, насколько тщательно планирование и развертывание… всё когда-нибудь ломается. Системы выходят из строя, ключевые функции перестают работать, и в какой-то момент карьеры каждого разработчика возникает проблема.
Природа этих проблем меняется с течением времени, но некоторые вещи остаются неизменными в том, как вы смотрите на проблемы и как люди могут работать, чтобы убедиться, что вы надёжно их исправите. И чтобы было ясно, мы не говорим о серийных багах в продакшене, мы говорим о проблемах, которые являются большими и объёмными, но в то же время деликатными. Следующие шаги применимы к людям на всех уровнях и могут дать некоторое представление о том, через что проходят люди на разных ролях в компании.
Шаг 1. Не паникуйте и определите проблему
В один прекрасный день базовая функциональность приложения перестаёт работать. Команда разработчиков собирается в совещательной комнате, чтобы найти решение проблемы. Инстинктивная реакция: «Быстрее, откатывай всё назад!» Это понятное чувство, мы создали проблемы, и, естественно, есть желание от них избавиться. Но с быстрыми действиями приходят и быстрые ошибки, и более опытные разработчики здесь резонно зададут вопрос: «А почему не работает?». Да, вашей реакцией может быть: «Кого это волнует? Наша ошибка видна всему миру!» Но спокойный характер и аналитическая манера поведения успокоят команду и убедят, что то, что происходит в этой комнате, правильно: надо задавать вопросы и исследовать.
Шаг 2. Диагностика и понимание источника проблемы
Это звучит как очевидная вещь, но из-за беспокойства и паники никто может не задаться этим вопросом. Оставьте проблему, чтобы убедиться, что вы знаете, почему это не работает. Перепроверьте журналы исключений, отдельные рабочие процессы или даже не было ли чего-то странного на системном уровне. Воспроизведите ошибку (здесь очень поможет, если ваши среды разработки настроены максимально идентично производственной среде). После того, как вы поймёте, что сделали не так, и наберётесь достаточно уверенности для следующего выпуска, начинайте откат. Это тонкий момент, но учитесь всегда использовать все возможности для поиска природы ошибки, прежде чем откатиться и потерять свой лучший источник информации: реальную проблему в дикой природе.
Также важно найти кого-то, кто займётся техническими вопросами и сможет помочь координировать усилия по исправлению (обычно это более старший разработчик), и кого-то, кто будет отвечать за «пиар для внешней среды» и «прикрытие с воздуха» тех, кто может захотеть потратить время на изучение ошибки (обычно это директор или технический руководитель). Это делается для защиты самого ценного ресурса во время кризиса: времени и внимания тех, кто действительно может реализовать план исправления.
Более технический специалист нужен, чтобы помочь разбить решение на этапы и делегировать или разделить работу, которую необходимо выполнить. А лидер инцидента (как его часто иронически называют) должен помогать, но не диктовать. Лучшие лидеры инцидентов задают два вопроса: «На каком этапе мы находимся?» и «Что вам нужно?», а также могут держать рассерженных пользователей подальше от специалистов, решающих проблему.
Окончание следует…
Источник: https://stackoverflow.blog/2023/05/03/dont-panic-a-playbook-for-managing-any-production-incident/
Без Паники! Пособие по Управлению Любым Инцидентом в Продакшене. Начало
Независимо от того, насколько сильна ваша организация, насколько тщательно планирование и развертывание… всё когда-нибудь ломается. Системы выходят из строя, ключевые функции перестают работать, и в какой-то момент карьеры каждого разработчика возникает проблема.
Природа этих проблем меняется с течением времени, но некоторые вещи остаются неизменными в том, как вы смотрите на проблемы и как люди могут работать, чтобы убедиться, что вы надёжно их исправите. И чтобы было ясно, мы не говорим о серийных багах в продакшене, мы говорим о проблемах, которые являются большими и объёмными, но в то же время деликатными. Следующие шаги применимы к людям на всех уровнях и могут дать некоторое представление о том, через что проходят люди на разных ролях в компании.
Шаг 1. Не паникуйте и определите проблему
В один прекрасный день базовая функциональность приложения перестаёт работать. Команда разработчиков собирается в совещательной комнате, чтобы найти решение проблемы. Инстинктивная реакция: «Быстрее, откатывай всё назад!» Это понятное чувство, мы создали проблемы, и, естественно, есть желание от них избавиться. Но с быстрыми действиями приходят и быстрые ошибки, и более опытные разработчики здесь резонно зададут вопрос: «А почему не работает?». Да, вашей реакцией может быть: «Кого это волнует? Наша ошибка видна всему миру!» Но спокойный характер и аналитическая манера поведения успокоят команду и убедят, что то, что происходит в этой комнате, правильно: надо задавать вопросы и исследовать.
Шаг 2. Диагностика и понимание источника проблемы
Это звучит как очевидная вещь, но из-за беспокойства и паники никто может не задаться этим вопросом. Оставьте проблему, чтобы убедиться, что вы знаете, почему это не работает. Перепроверьте журналы исключений, отдельные рабочие процессы или даже не было ли чего-то странного на системном уровне. Воспроизведите ошибку (здесь очень поможет, если ваши среды разработки настроены максимально идентично производственной среде). После того, как вы поймёте, что сделали не так, и наберётесь достаточно уверенности для следующего выпуска, начинайте откат. Это тонкий момент, но учитесь всегда использовать все возможности для поиска природы ошибки, прежде чем откатиться и потерять свой лучший источник информации: реальную проблему в дикой природе.
Также важно найти кого-то, кто займётся техническими вопросами и сможет помочь координировать усилия по исправлению (обычно это более старший разработчик), и кого-то, кто будет отвечать за «пиар для внешней среды» и «прикрытие с воздуха» тех, кто может захотеть потратить время на изучение ошибки (обычно это директор или технический руководитель). Это делается для защиты самого ценного ресурса во время кризиса: времени и внимания тех, кто действительно может реализовать план исправления.
Более технический специалист нужен, чтобы помочь разбить решение на этапы и делегировать или разделить работу, которую необходимо выполнить. А лидер инцидента (как его часто иронически называют) должен помогать, но не диктовать. Лучшие лидеры инцидентов задают два вопроса: «На каком этапе мы находимся?» и «Что вам нужно?», а также могут держать рассерженных пользователей подальше от специалистов, решающих проблему.
Окончание следует…
Источник: https://stackoverflow.blog/2023/05/03/dont-panic-a-playbook-for-managing-any-production-incident/
👍10
День 1575. #DevOps #ProjectManagement
Без Паники! Пособие по Управлению Любым Инцидентом в Продакшене. Окончание
Начало
Шаг 3. Исправление: начнём работать над проблемой
Мы знаем, что у нас есть проблема, мы знаем источник проблемы, теперь давайте составим план и исправим её. Мы все любим переходить к этому шагу, сразу приступать к исправлению. И иногда у нас есть такая роскошь для простых вопросов, когда проблема настолько очевидна, что подтверждение и понимание источника проблемы — быстрые шаги. Но если проблема зашла далеко или она серьезная, нужно поступать более обдуманно.
Тут координатор поможет расставить приоритеты в работе, выяснить, где находятся самые важные шаги по смягчению последствий, и убедиться, что у всех заинтересованных сторон есть чёткие ожидания относительно того, что надо делать и какой будет результат. Разработчик, работающий над проблемой, обязан привлечь этого человека, убедиться, что он предоставит ему ресурсы, необходимые для решения проблемы. Это может быть время, доступ или другие люди, у которых есть специфические знания. Это важная тема на данном этапе: дать инженерам то, что им нужно, чтобы исправить ситуацию. Возможно, это должно волновать всех инженеров-руководителей не только тогда, когда что-то пошло не так, и жизненно важные рабочие процессы встали.
Больше всего во время кризиса не хватает не информации или помощи других разработчиков, а возможности сфокусироваться. Это может показаться странным, но это чувство знакомо любому, кто был в одной лодке с лидерами, которые паникуют или никогда не понимали заблуждений мифического человеко-месяца. Они с нетерпением ждут новостей о ходе работы, и что может быть лучше, чем собирать всех на митинги четыре раза в день, чтобы узнать, как продвигаются дела. А это постоянные отвлечения, переключения контекста и обновления багтрекеров. Способность сосредоточиться и избавиться от отвлекающих факторов - самый важный фактор для решения проблемы.
Шаг 4. Проверка и обучение
Если все пойдёт хорошо, тесты подтвердятся, и вся ценная информация, полученная на шагах 1 и 2, даст вам уверенность в новых планах тестирования, вы можете развернуть исправление. Как только оно будет опубликовано, дайте время команде на всех уровнях, чтобы изучить его и подтвердить, что всё работает как надо. Если инженерам в начале этих инцидентов даются время и свобода, то они более уверенно и спокойно относятся к последующим релизам и исправлениям.
Однако, публикация исправления и уверенность команды в его правильности – лишь половина дела. Теперь нужно сделать так, чтобы болезненный и возможно дорогостоящий опыт этой проблемы способствовал развитию команды. Люди часто воспринимают крупные кризисы, как проблему, которая никогда больше не повторится, что совершенно неразумно. Часто лучшее обучение — это учиться справляться с проблемами, а не притворяться, будто мы можем их избежать.
В конце концов, чаще всего всё сводится к элементарной человеческой ошибке. Поэтому техническому руководителю нужно быть больше сосредоточенным не на предотвращении ошибок, а на оттачивании способности команды справляться с ними. Да, важна работа по предотвращению будущих подобных ошибок. Но часто есть больше возможностей для улучшения того, как команда реагирует на ошибку. Как дать инженерам больше возможностей для концентрации? Как можно ускорить расследование инцидента? Или даже кто лучше всего справляется с коммуникацией между разными специалистами или командами и какая информация им нужна?
Источник: https://stackoverflow.blog/2023/05/03/dont-panic-a-playbook-for-managing-any-production-incident/
Без Паники! Пособие по Управлению Любым Инцидентом в Продакшене. Окончание
Начало
Шаг 3. Исправление: начнём работать над проблемой
Мы знаем, что у нас есть проблема, мы знаем источник проблемы, теперь давайте составим план и исправим её. Мы все любим переходить к этому шагу, сразу приступать к исправлению. И иногда у нас есть такая роскошь для простых вопросов, когда проблема настолько очевидна, что подтверждение и понимание источника проблемы — быстрые шаги. Но если проблема зашла далеко или она серьезная, нужно поступать более обдуманно.
Тут координатор поможет расставить приоритеты в работе, выяснить, где находятся самые важные шаги по смягчению последствий, и убедиться, что у всех заинтересованных сторон есть чёткие ожидания относительно того, что надо делать и какой будет результат. Разработчик, работающий над проблемой, обязан привлечь этого человека, убедиться, что он предоставит ему ресурсы, необходимые для решения проблемы. Это может быть время, доступ или другие люди, у которых есть специфические знания. Это важная тема на данном этапе: дать инженерам то, что им нужно, чтобы исправить ситуацию. Возможно, это должно волновать всех инженеров-руководителей не только тогда, когда что-то пошло не так, и жизненно важные рабочие процессы встали.
Больше всего во время кризиса не хватает не информации или помощи других разработчиков, а возможности сфокусироваться. Это может показаться странным, но это чувство знакомо любому, кто был в одной лодке с лидерами, которые паникуют или никогда не понимали заблуждений мифического человеко-месяца. Они с нетерпением ждут новостей о ходе работы, и что может быть лучше, чем собирать всех на митинги четыре раза в день, чтобы узнать, как продвигаются дела. А это постоянные отвлечения, переключения контекста и обновления багтрекеров. Способность сосредоточиться и избавиться от отвлекающих факторов - самый важный фактор для решения проблемы.
Шаг 4. Проверка и обучение
Если все пойдёт хорошо, тесты подтвердятся, и вся ценная информация, полученная на шагах 1 и 2, даст вам уверенность в новых планах тестирования, вы можете развернуть исправление. Как только оно будет опубликовано, дайте время команде на всех уровнях, чтобы изучить его и подтвердить, что всё работает как надо. Если инженерам в начале этих инцидентов даются время и свобода, то они более уверенно и спокойно относятся к последующим релизам и исправлениям.
Однако, публикация исправления и уверенность команды в его правильности – лишь половина дела. Теперь нужно сделать так, чтобы болезненный и возможно дорогостоящий опыт этой проблемы способствовал развитию команды. Люди часто воспринимают крупные кризисы, как проблему, которая никогда больше не повторится, что совершенно неразумно. Часто лучшее обучение — это учиться справляться с проблемами, а не притворяться, будто мы можем их избежать.
В конце концов, чаще всего всё сводится к элементарной человеческой ошибке. Поэтому техническому руководителю нужно быть больше сосредоточенным не на предотвращении ошибок, а на оттачивании способности команды справляться с ними. Да, важна работа по предотвращению будущих подобных ошибок. Но часто есть больше возможностей для улучшения того, как команда реагирует на ошибку. Как дать инженерам больше возможностей для концентрации? Как можно ускорить расследование инцидента? Или даже кто лучше всего справляется с коммуникацией между разными специалистами или командами и какая информация им нужна?
Источник: https://stackoverflow.blog/2023/05/03/dont-panic-a-playbook-for-managing-any-production-incident/
👍8
День 1587. #ЗаметкиНаПолях #DevOps
Создаём Конвейер CI/CD в GitHub Actions
Благодаря CI/CD вы можете значительно сократить объем ручных операций и больше сосредоточиться на создании ПО, обеспечивая более быстрые и надёжные развёртывания.
CI/CD — это метод автоматизации рабочего процесса разработки и развёртывания ПО. Непрерывная интеграция (CI) - это процесс автоматизации синхронизации нового кода с репозиторием. Любые изменения в коде приложения немедленно собираются, тестируются и объединяются. Непрерывная доставка или развёртывание (CD) обеспечивает развёртывание изменений в производственную (или другую) среду.
Если вы используете GitHub, вы можете использовать GitHub Actions, чтобы создавать рабочие процессы сборки и тестирования каждого коммита в вашем репозитории или развёртывания в рабочую среду при создании нового тега.
Нужно создать рабочий процесс, который будет запускаться, когда в вашем репозитории происходит какое-либо событие. Примеры событий: коммит в основной ветке, создание тега или запуск рабочего процесса вручную. Например, для сборки и тестирования:
- Определяем событие для запуска рабочего процесса (при коммите в ветку main)
- Настраиваем.NET SDK с версией из
Добавив это действие в свой репозиторий GitHub, вы начнёте получать мгновенную обратную связь после каждого коммита. При сбое выполнения рабочего процесса из-за ошибки сборки или неудачного теста вы получите уведомление на email.
Непрерывная доставка - реальная ценность процесса CI/CD. Вы делаете изменение, и уже через несколько минут ваш код собран, протестирован и выложен в рабочую среду. Вот пример сценария развёртывания:
- Добавление шага публикации и настройка выходного пути
- Использование действия azure/webapps-deploy@v2 для развёртывания в Azure.
Если вам нужно безопасно и надёжно использовать секретные данные в рабочих процессах, вы можете определить секреты GitHub и использовать их в действиях, не добавляя их в систему управления версиями. В примере выше использован
Источник: https://www.milanjovanovic.tech/blog/build-ci-cd-pipeline-with-github-actions-and-dotnet
Создаём Конвейер CI/CD в GitHub Actions
Благодаря CI/CD вы можете значительно сократить объем ручных операций и больше сосредоточиться на создании ПО, обеспечивая более быстрые и надёжные развёртывания.
CI/CD — это метод автоматизации рабочего процесса разработки и развёртывания ПО. Непрерывная интеграция (CI) - это процесс автоматизации синхронизации нового кода с репозиторием. Любые изменения в коде приложения немедленно собираются, тестируются и объединяются. Непрерывная доставка или развёртывание (CD) обеспечивает развёртывание изменений в производственную (или другую) среду.
Если вы используете GitHub, вы можете использовать GitHub Actions, чтобы создавать рабочие процессы сборки и тестирования каждого коммита в вашем репозитории или развёртывания в рабочую среду при создании нового тега.
Нужно создать рабочий процесс, который будет запускаться, когда в вашем репозитории происходит какое-либо событие. Примеры событий: коммит в основной ветке, создание тега или запуск рабочего процесса вручную. Например, для сборки и тестирования:
name: Build & TestЗдесь мы:
on:
push:
branches:
- main
env:
DOTNET_VERSION: "7.0.x"
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup .NET
uses: actions/setup-dotnet@v3
with:
dotnet-version: ${{ env.DOTNET_VERSION }}
- name: Install dependencies
run: dotnet restore WebApi
- name: Build
run: dotnet build WebApi --configuration Release --no-restore
- name: Test
run: dotnet test WebApi --configuration Release --no-build
- Определяем событие для запуска рабочего процесса (при коммите в ветку main)
- Настраиваем.NET SDK с версией из
env.DOTNET_VERSION
- Восстанавливаем зависимости, затем собираем и тестируем проект с помощью команд dotnet CLIДобавив это действие в свой репозиторий GitHub, вы начнёте получать мгновенную обратную связь после каждого коммита. При сбое выполнения рабочего процесса из-за ошибки сборки или неудачного теста вы получите уведомление на email.
Непрерывная доставка - реальная ценность процесса CI/CD. Вы делаете изменение, и уже через несколько минут ваш код собран, протестирован и выложен в рабочую среду. Вот пример сценария развёртывания:
name: PublishОн очень похож на предыдущий, со следующими отличиями:
on:
push:
branches:
- main
env:
AZURE_WEBAPP_NAME: web-api
AZURE_WEBAPP_PACKAGE_PATH: "./publish"
DOTNET_VERSION: "7.0.x"
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup .NET
uses: actions/setup-dotnet@v3
with:
dotnet-version: ${{ env.DOTNET_VERSION }}
- name: Build and Publish
run: |
dotnet restore WebApi
dotnet build WebApi -c Release --no-restore
dotnet publish WebApi -c Release --no-build
--output '${{ env.AZURE_WEBAPP_PACKAGE_PATH }}'
- name: Deploy to Azure
uses: azure/webapps-deploy@v2
with:
app-name: ${{ env.AZURE_WEBAPP_NAME }}
publish-profile: ${{ secrets.AZURE_PUBLISH_PROFILE }}
package: '${{ env.AZURE_WEBAPP_PACKAGE_PATH }}'
- Добавление шага публикации и настройка выходного пути
- Использование действия azure/webapps-deploy@v2 для развёртывания в Azure.
Если вам нужно безопасно и надёжно использовать секретные данные в рабочих процессах, вы можете определить секреты GitHub и использовать их в действиях, не добавляя их в систему управления версиями. В примере выше использован
secrets.AZURE_PUBLISH_PROFILE для доступа к профилю публикации в экземпляре App Service.Источник: https://www.milanjovanovic.tech/blog/build-ci-cd-pipeline-with-github-actions-and-dotnet
👍14