Переїзд на більші робочі простори без очікування для кого б то не було

Кожен проєкт Mythex отримує власний робочий простір: маленький хмарний комп'ютер, де агент пише код і працює перегляд вашого застосунку. Ми підняли пам'ять нових робочих просторів з 1 ГБ до 2 ГБ, але старі залишилися на 1 ГБ — у день перевірки це було близько чверті від них. Наше перше виправлення переносило проєкт у більший робочий простір, коли його востаннє відкривали. У перший же день у продакшені це змусило одну людину чекати сім хвилин. Ми поставили жорсткий ліміт часу, а потім взагалі прибрали перенесення з відкриття проєкту.

Чому старі робочі простори лишалися маленькими

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

Це було важливо. Один із маленьких просторів закінчив пам'ять під час git push, коли запускався його перегляд, і одинадцять хвилин не відповідав. Через це публікація провалилася.

Перша спроба: перенести проєкт, коли він прокидається

Робочі простори призупиняються, коли ними ніхто не користується, і прокидаються, коли відкривається проєкт. Пробудження здавалося правильним моментом для перенесення, бо в проєкті ще ніхто не працює.

Перенесення працювало так:

1. Перевірити розмір. Якщо робочий простір менший за 2 ГБ, перенести його. Якщо розмір невідомий, нічого не робити.
2. Не заважати публікації. Публікація читає файли робочого простору, тож якщо вона виконується, перенесення пропускається.
3. Запакувати проєкт. Заархівувати все в проєкті — включно з його історією git, тобто кожною контрольною точкою проєкту, і файлом .env застосунку, який належить власникові, — але виключити встановлені залежності (node_modules), які можна встановити знову.
4. Перенести напряму. Передати архів зі старого робочого простору в новий на 2 ГБ, щоб він ніколи не мусив поміститися в пам'ять нашого сервера.
5. Порівняти перед перемиканням. Порахувати файли, прочитати останню контрольну точку і порахувати контрольні точки в обох просторах. Перемикати лише тоді, коли всі три значення збігаються.
6. При будь-якій помилці зберегти старий. Будь-яка помилка або невідповідність видаляє новий робочий простір і відкриває проєкт у старому, як і раніше.

Одна деталь у порівнянні важила більше, ніж здається. Перевірка виконувалася від імені адміністратора, а git відмовляється читати репозиторій, що належить іншому користувачеві. Обидві сторони нічого не виводили — і «нічого» дорівнювало «нічому», тож перевірка проходила, не порівнюючи жодної історії. Ми вказали git довіряти каталогу і додали тест, щоб це не повернулося.

Що пішло не так у перший день

У перший день у продакшені пакування одного проєкту досягло п'ятихвилинного тайм-ауту команди — всередині пробудження. Власник чекав сім хвилин, поки його робочий простір відкриється. А оскільки перенесення провалилося, проєкт лишався маленьким, тож наступне відкриття спробувало б знову і змусило б їх чекати знову.

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

Друга спроба: жорсткий бюджет

Того ж дня ми змінили чотири речі:

• Одна хвилина на все перенесення. Кожен крок — перевірка розміру, пакування, створення нового робочого простору, копіювання, розпакування, порівняння — ділить один бюджет у 60 секунд. Коли він закінчується, проєкт відкривається в старому робочому просторі.
• Зупиняти роботу, а не лише очікування. Припинити очікувати з нашого боку недостатньо, якщо архівування все ще працює всередині робочого простору, яким ось-ось скористається власник. Тепер кожну команду архівування вбивають всередині самого робочого простору незадовго до кінця бюджету. Якщо новий робочий простір з'являється після того, як ми здалися, його викидають.
• Не змушувати власника чекати на прибирання. Видалення тимчасового архіву тепер відбувається у фоновому режимі.
• Не пробувати знову при кожному відкритті. Проєкт, який не вдалося перенести, не чіпають 24 години, тож невдача коштує щонайбільше однієї затримки на день, а не однієї на кожне відкриття.

Третя спроба: прибрати перенесення з пробудження

Це зробило найгірший випадок однохвилинним. Але хвилина все одно є хвилиною, і ми усвідомили, що перенесення взагалі не потрібно ставити на чий-небудь шлях.

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

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

Що ми з цього винесли

• Змінити розмір не завжди можливо. Коли платформа фіксує розмір під час створення, підвищення типового значення допомагає лише новим речам. Плануйте для старих.
• «Ніхто її ще не використовує» все одно означає, що хтось чекає. Робота, яка відбувається на шляху до продукту, — це робота, за якою людина спостерігає.
• Ставте бюджет на все, що стоїть на шляху користувача, і зупиняйте роботу, коли бюджет вичерпано. Тайм-аут з нашого боку, поки команда продовжує працювати деінде, лише переміщує проблему.
• Одноразова міграція належить до одноразового завдання. Приховування її в повсякденних діях робить її дешевшою у написанні і дорожчою в запуску.
• Тестуйте свої перевірки безпеки. Порівняння, яке нічого не порівнює, виглядає точно так само, як те, що пройшло успішно.

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