Production-аудит: чи готовий проєкт до реальних користувачів

Що таке production-аудит простими словами

Спік удома один торт. Для себе. Смачно - ти задоволений. А тепер уяви: завтра до тебе ввалиться 300 гостей. Кожному подавай шматок, у пʼятьох алергія на горіхи, троє намагаються поцупити торт цілком, а один незворушно просить чек.

Відчуваєш різницю? «Спік торт удома» і «нагодував 300 людей» - це дві різні професії. Перше - твій проєкт на ноутбуці. Друге - прод (production): момент, коли ним починають користуватися чужі, незнайомі та геть непередбачувані люди.

Чому «працює в мене» не дорівнює «готово до запуску»

Ти вайбкодер. Зібрав штуку, вона працює, і руки сверблять показати її світові - викласти, кинути посилання друзям, увімкнути рекламу. Найсолодший момент. І найнебезпечніший. Бо саме тут найчастіше прилітає по обличчю:

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

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

Прод Прод (production) - «бойова» версія проєкту, якою користуються реальні люди. Протилежність - твій локальний компʼютер або тестовий майданчик, де можна ламати що завгодно без наслідків. прощає значно менше, ніж твій ноутбук. Гарна новина: ШІ вміє прогнати проєкт по чек-листу готовності. Треба лише знати, що просити.

Як ШІ проводить аудит готовності до запуску

Грамотний аудит - це не «глянь, чи все ок». Це суворий порядок перевірок, від дешевих до дорогих. Скіл production-audit іде рівно так.

Крок 1. Що взагалі викочуємо в прод

Спершу ШІ дивиться, що змінилося і що поїде на бойовий сервер: останні правки, поточна гілка, чим ця версія відрізняється від попередньої. Логіка проста - не можна перевіряти те, чого не розумієш.

Крок 2. Небезпечні зони, де все ламається найчастіше

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

Крок 3. Короткий вердикт можна чи не можна

Жодного «ну начебто норм». По суті: можна запускати чи ні. А якщо ні - що лагодити першочергово.

Чотири зони, де найчастіше падає прод

Скіл production-audit дивиться на проєкт крізь кілька «лінз». Ось чотири головні. Вивчи їх - це твій особистий чек-лист готовності.

Вхід і доступ: безпека користувачів

Найстрашніший сон - чужий бачить те, що не повинен. ШІ перевіряє: чи розділені публічні сторінки та адмінка; чи перевіряється доступ на сервері, а не за принципом «сховали кнопку, і зійде»; чи не витекли секрети Секрети - паролі, ключі доступу до API, токени оплати. Те, що має лежати в захищеному місці, а не бути зашитим прямо в коді сайту, який бачить будь-який користувач. в код, який браузер роздає кожному зустрічному.

Гроші й оплата без подвійних списань

Є платежі - є зона підвищеного ризику. Ключове слово тут - ідемпотентність Ідемпотентність - мудроване слово з простим змістом: якщо одна й та сама дія випадково повториться двічі, результат має бути таким, як від одного разу. Замовлення оплатили один раз - товар іде один раз, навіть якщо система надіслала сповіщення тричі. . Платіжні системи обожнюють слати одне сповіщення по кілька разів. Не готовий до цього - людина заплатить один раз, а отримає (або втратить) двічі.

Дані й шлях назад

Головне питання: чи є шлях назад? Оновлення зіпсувало базу - чи можна повернути як було? ШІ перевіряє, що зміни бази накочуються чисто і що план відкату не на словах, а напоготові.

Запуск з нуля на чистому сервері

Звучить банально, а валить проєкти з прикрою регулярністю. Чи підніметься проєкт на чистому компʼютері строго за інструкцією? У тебе ж усе налаштовано роками й тримається на памʼяті. А новий сервер порожній. І памʼяті в нього немає.

Шлях відкату: головне правило безпечного запуску

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

Шлях відкату Шлях відкату (rollback) - заздалегідь підготовлений спосіб швидко повернути проєкт до робочого стану, якщо нова версія все зламала. Як кнопка «скасувати», але для цілого сайту. - твоя страховка. Будь-хто, хто запускався не раз, знає твердо: рано чи пізно ти викотиш оновлення, і воно щось зламає. Питання не «якщо», а «коли». І в цей момент усе вирішує рівно одне - чи можеш ти швидко повернути як було.

Готовий до людей чи ще ні: чек-лист готовності

Приклад із життя: три пожежі за один вечір

Ти зробив сайт із продажу стікерпаків. Усе крутиться: товар додається, оплата проходить, друзі потестили - кайф. Вмикаєш рекламу, за вечір приходить 200 людей. І понеслося:

1. Платіжна система надіслала сповіщення про оплату двічі (так буває частіше, ніж здається) - і один покупець отримав два списання. Ідемпотентності не було.
2. Хтось поміняв в адресному рядку номер замовлення на чужий - і побачив чужу адресу доставки. Доступ перевірявся лише на сторінці, а не на сервері.
3. Ти в паніці викотив «фікс», він доламав решту, а робочої версії в тебе вже немає. Відкату не було.

Один вечір - три пожежі. І всі три ШІ знайшов би заздалегідь, попроси ти його до запуску. Ось як просити.

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

Безпека. Чи перевіряється доступ на стороні сервера, а не лише схованою кнопкою. Чи не витекли паролі та ключі в код, який бачить браузер.
Гроші. Якщо є оплата - що буде, якщо сповіщення про платіж прийде двічі. Чи не спишеться й не видасться товар повторно.
Дані. Чи можна відкотити зміни бази, якщо нова версія їх зіпсує.
Запуск. Чи підніметься проєкт на чистому сервері за інструкцією, без знань, які є лише в моїй голові.
Телефон. Чи працюють головні сценарії та форми на мобільному екрані.
Наприкінці дай короткий вердикт: можна запускати чи ні. Якщо ні - список того, що лагодити першочергово, за важливістю. І перелічи, що саме ти перевірив: які файли й місця.

Вердикт аудиту: можна, не можна чи із застереженнями

Гарний аудит закінчується рішенням, а не задумливим зітханням. Скіл production-audit користується для цього простою шкалою - перекладемо її людською:

• Заблоковано - не запускай, доки не полагодиш головне (немає перевірки доступу до чужих даних, оплата може списати двічі, немає відкату).
• Ризиковано - запускай обережно, на маленькій групі, а не на всю аудиторію разом.
• Можна із застереженнями - запускай, якщо свідомо приймаєш решту дрібних ризиків.
• Упевнено - явних блокерів не видно.

Часті помилки під час запуску в прод

• Вважати зелені тести готовністю. Тести - про «код робить задумане». Аудит - про «прод не впаде під людьми». Різні питання.
• Запускати без відкату. Рано чи пізно щось зламається. Без кнопки «повернути як було» це вже катастрофа, а не просто прикрість.
• Перевіряти доступ лише на сторінці. Сховати кнопку - не захист, а фіговий листок. Доступ зобовʼязаний перевірятися на сервері.
• Зашивати секрети в код. Паролі й ключі в коді сторінки видно будь-кому. Їм місце в захищеному сховищі, а не на вітрині.
• Забувати про ідемпотентність в оплаті. Подвійне сповіщення про платіж дорівнює подвійному списанню, якщо проєкт до цього не готовий.
• Тестувати лише на своєму великому екрані. Половина людей прийде з телефона. Форму, яку там не натиснути, ніхто не заповнить.
• Приймати вердикт без списку перевіреного. Не сказав ШІ, що саме дивився, - отже, це не аудит, а здогадка з упевненим обличчям.