Прихований реєстр коду: відстеження вуглецевого боргу всередині нашого програмного забезпечення

Особливості

• Кожен рядок коду має невидиму вартість. З масштабуванням програмного забезпечення зростає споживання енергії та викиди, які воно генерує.
• Цей зростаючий слід формує те, що багато інженерів зараз називають вуглецевим боргом: накопичення енергетичних відходів, спричинене неефективною архітектурою, надлишковими обчисленнями або занедбаним очищенням.
• Проблема вже не обмежується теорією. Глобальні обсяги даних зростають швидше, ніж підвищення ефективності, призначене для їх компенсації, і лише кілька команд мають інструменти для вимірювання того, що їхні системи насправді викидають.
• Оскільки інженери контролюють, як і де працює код, реальний прогрес починається всередині робочих процесів розробки, а не в залах засідань.
• Оскільки видимість вуглецю наближається до самого коду, програмні проєкти незабаром можуть оцінюватися не лише за швидкістю та стабільністю, але й за тим, наскільки відповідально вони використовують енергію.

Борг, який ми не відстежуємо

Команди говорять про технічний борг на кожному спринті. Вони відстежують запахи коду, потреби в рефакторингу, складність модулів і роздутість збірки. Але майже ніхто не відстежує енергетичний відтік, вбудований у їхні системи, і це робить цю сліпу зону реальною.

\ Кожна неефективність у коді, як-от зайві цикли, надлишкові запити до бази даних і фонові завдання в режимі очікування, перетворюється на використання енергії. Запускайте тисячі або мільйони разів на день, і те, що здається тривіальним, стає вимірюваними викидами. Дослідники почали кількісно оцінювати це: наприклад, структура Green Algorithms показує, що час обчислень, використання пам'яті та ефективність центру обробки даних можна перетворити на оцінки еквівалента вуглецю для будь-якого обчислювального завдання.

\ У масштабі центру обробки даних неефективність посилюється. Одна біла книга виявила, що сервери можуть споживати від 60% до 90% своєї пікової потужності навіть у режимі очікування. Помножте це на десятки серверів, і тижні витрачених циклів перетворюються на десятки кілограмів еквівалента CO2.

\ Кожна продуктова команда тепер працює з невидимим балансовим звітом, який фіксує вуглець разом зі складністю.

Прихована книга: що насправді означає вуглецевий борг

Термін вуглецевий борг походить з екологічного обліку, де він описує накопичені викиди, які система або суб'єкт "позичив" проти майбутніх бюджетів з недостатніми компенсаціями. (Він ґрунтується на ширшому понятті екологічного або кліматичного боргу.) Тепер технологи запозичують цю фразу для опису програмних систем, неефективність яких з часом накопичує приховані енергетичні витрати.

\ У програмному забезпеченні вуглецевий борг зростає, коли шари надлишкового коду, надмірно забезпеченої інфраструктури та важких фреймворків залишаються неперевіреними. Модуль, який створює непотрібні фонові завдання, або служба, яка надмірно отримує дані, спалює цикли процесора, які споживають енергію.

\ Коли інфраструктура розміщена з щедрим запасом "про всяк випадок", цей запас часто залишається недостатньо використаним, але все ще споживає базову потужність. Сервери та служби часто споживають від 27% до 36% пікової потужності навіть при невеликому навантаженні.

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

\ Далі ми простежимо, як код накопичує викиди, щоб ви могли побачити, звідки насправді походить борг.

Як код накопичує викиди

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

Як крихітні цикли перетворюються на великі витрати

Дослідження мобільного програмного забезпечення показує, що запахи енергетичного коду можуть різко збільшити споживання, і в деяких випадках вони можуть споживати до 87 разів більше енергії, ніж чисті версії. Подальша робота виявила, що виправлення цих шаблонів забезпечило на практиці підвищення ефективності від 4% до 30%. Ці результати підкріплюють ширшу думку: повторювані, здавалося б, незначні шаблони з часом накопичують реальне споживання енергії.

\ Подібні відходи з'являються в повсякденних інженерних звичках: надлишкові запити до бази даних, непотрібні повторні рендеринги інтерфейсу та неактивні кінцеві точки API — усе це підтримує активність процесорів, споживаючи енергію без покращення продуктивності.

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

Вимірювання того, чого ми не бачимо

Відстеження того, скільки енергії насправді використовує програмне забезпечення, складніше, ніж здається. Структура інтенсивності вуглецю програмного забезпечення (SCI) від Green Software Foundation є однією з перших реальних спроб зробити це вимірюваним, наприклад, зіставлення часу обчислень, використання пам'яті та передачі даних з фактичними даними про енергію.

\ Такі інструменти, як Cloud Carbon Footprint і CodeCarbon, зараз роблять цю формулу на крок далі, вбудовуючи оцінки енергії безпосередньо в конвеєри збірки та інформаційні панелі, щоб розробники могли бачити вплив на навколишнє середовище поряд із показниками продуктивності. Це узгоджується з ширшими розмовами всередині спільноти DevOps, де команди починають досліджувати практичні способи вбудовування сталості в робочі процеси збірки та розгортання.

\ Виклик полягає в перекладі виконання коду на фізичні терміни. Кожен спожитий ват залежить від типу процесора, ефективності охолодження та вуглецевої інтенсивності мережі, яка живить центр обробки даних. Те саме робоче навантаження може мати частку викидів на інфраструктурі з високою часткою відновлюваних джерел енергії порівняно з мережами, що працюють на викопному паливі.

\ Логіка, що лежить в основі цих інструментів, не далека від того, як прогнозна аналітика використовується для виявлення прихованих операційних витрат в інших галузях, перетворюючи здогадки на вимірюване розуміння. Доки такий вид видимості не стане стандартом у середовищах розробників, більшість команд продовжуватимуть оптимізувати продуктивність, залишаючись сліпими до енергії, що стоїть за нею.

Розрив у управлінні: чому вуглець ще не є метрикою кодування

Сталість все ще знаходиться поза більшістю інженерних робочих процесів. У багатьох компаніях звітність про вуглець живе з командами об'єктів або операцій, а не з людьми, які пишуть або розгортають код.

\ В результаті енергетична вартість випуску рідко обговорюється при плануванні спринту або посмертних аналізах. Agile-церемонії відстежують швидкість, сторі-поінти та частоту помилок, але не викиди.

Відсутня метрика

Мало середовищ DevOps включають "вуглецеві спринти" або вуглецеві бюджети, хоча їх можна було б відстежувати так само, як час безперебійної роботи або затримку. Звіт, заснований на відповідях понад 2000 практиків програмного забезпечення, виявив, що більшість організацій все ще перебувають на ранніх стадіях вимірювання викидів, пов'язаних з програмним забезпеченням. Інші підтвердили це, зазначивши, що метрики сталості залишаються значною мірою відсутніми в конвеєрах безперервної інтеграції та доставки.

\ Цей розрив починає закриватися. Деякі спільноти з відкритим кодом почали експериментувати з "зеленими комітами" для позначення енергоефективних змін, а корпоративні інформаційні панелі починають відображати дані про сталість поряд з ключовими показниками ефективності. Коли ця видимість покращується, пріоритети дизайну зміщуються в бік розпаду та стримування, будуючи системи, які знають, коли сповільнитися, скоротитися або повністю вимкнутися.

Проєктування для розпаду: зробити ефективність за замовчуванням

Архітектори, які займаються довгоживучими системами, часто говорять про архітектурну ерозію або розпад дизайну, як поступове розходження між передбачуваною структурою та реальністю виконання. Ерозія архітектури є добре відомим ризиком у системах, оскільки функції накопичуються, а ярлики поширюються. Один із способів протидіяти цьому дрейфу — створювати системи, які самооптимізуються або автоматично закривають невикористовувані процеси, обрізаючи неактивні модулі або скорочуючи недостатньо використовувані служби на основі сигналів реального використання.

Обрізати, архівувати, відхиляти

Трактування розпаду коду як функції означає вбудовування процедур, які виконують періодичне очищення: архівування застарілих API, виведення з експлуатації неактивних модулів або забезпечення гігієни залежностей. Фреймворки можуть вимагати, щоб бібліотеки, які не використовуються для X випусків, були позначені або видалені. З часом зміщення відбувається від "необмеженого масштабування" до сталого масштабування, системи розро