Портал №1 по управлению цифровыми
и информационными технологиями

Применима ли концепция “сдвиг влево” (shift left) для инженеров по надёжности систем (SRE)?

Опубликовано 24 октября 2021
Рубрики: Agile, Scrum, разработка ПО, DevOps
Комментарии

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

В чём суть идеи “сдвига влево”?

Сдвиг влево – это обнаружение прикладных проблем на ранней стадии процесса разработки программного обеспечения. Основная идея сдвига влево заключается в том, что вместо того, чтобы непосредственно перед развертыванием тестировать программное обеспечение на наличие ошибок, проблем с безопасностью или других проблем, команды должны начать процесс тестирования как можно раньше. Другими словами, они должны перенести часть тестирования на “левую” часть жизненного цикла разработки программного обеспечения вместо тестирования только в середине — отсюда и термин “сдвиг влево”.

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

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

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

Сдвиг влево и SRE-инженер

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

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

Тем не менее, стратегия сдвига влево может помочь SRE-инженеру лучше выполнять свою работу по нескольким причинам:

  • Меньше проблем в производстве. Наиболее очевидно, что сдвиг влево снижает скорость, с которой проблемы с надежностью достигают производственных сред. В свою очередь, это сводит к минимуму количество инцидентов, на которые необходимо реагировать SRE-инженеру.
  • Оптимизация программного обеспечения перед развертыванием. Помогая выявлять проблемы с надежностью на ранних этапах процесса разработки, сдвиг влево является одним из способов для SRE-инженеров получить представление, необходимое для сотрудничества с разработчиками по обеспечению надежности приложений. Сдвиг влево помогает выделить ошибочные зависимости или неоптимальные архитектурные шаблоны.
  • Детальная информация о надежности. Поскольку сдвиг влево – отличный способ отследить проблемы программного обеспечения до конкретного кода, который их запускает, он обеспечивает очень высокую прозрачность в отношении надежности. Это может помочь SRE-инженерам найти самые слабые звенья в коде или архитектуре приложения. Эти слабые места может быть сложнее обнаружить при мониторинге или наблюдении за приложением в целом.

Как SRE-инженеры могут следовать концепции “сдвига влево”?

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

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

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

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

Почему SRE-инженерам тоже нужно смещаться влево?

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

Оригинал статьи доступен по ссылке.

Комментариев: 1

  • Хорошая тема, и заметка хорошая.

    Shift Left – прекрасная идея, я её полностью поддерживаю. На практике с воплощением бывают сложности. Я сталкивался с двумя:
    1) никто не понимает что это на самом деле такое, как и что можно “сдвинуть влево”. Эта сложность устраняется разъяснительной работой с персоналом.
    2) вроде понятно, но мы делаем то, что делаем, и так, как делаем, то есть ничего никуда фактически не сдвигается. Вот эта сложность очень больная.

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

    В заметке же объединяются два мира. Отлично!

    Очень смущает вот это:

    “Первым шагом в этом процессе является донесение понимания пользы от сдвига влево до разработчиков.”

    И далее объясняется, как я понял, примерно та же мысль: так как SRE выиграют от сдвига влево, то вот пусть SRE разрабам и объясняют насколько, как именно и почему нужно “сдвинуться”.

    На мой взгляд, это нерабочее решение. Во-первых, это не дело SRE. Во-вторых, мало у них будет аргументов, устанут. В-третьих, и это главное – снова эксплуатация начинает лечить разработку, находясь в позиции просящего (ниже по течению).

    Есть решение получше. Нужно вспомнить, что такое SRE на самом деле. Это не эксплуатация, которую теперь модно назвали. Это бюджет на риски, и если бюджет выбран – разрабы перестают кодить и начинают заниматься эксплуатацией. Это отличный мотиватор сдвинуться влево. Он встроен в идею SRE. И он работает.


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM