Як перевірити та оптимізувати, коли ви не можете відтворити навколишнє середовище?

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

Сьогодні я ні. Сьогодні я опиняюсь у середовищі, основний акцент якого робиться на масштабованості. Відтворення навколишнього середовища є надмірно дорогим. Беручи фрагмент середовища, хоча він правдоподібний (деякі частини потрібно буде імітувати або використовувати в режимі одного примірника, який вони не роблять), якийсь спосіб перемагає мету, оскільки це затьмарює одночасність і завантажує це реальна система зустрічається. Навіть невелика «тестова» система має свої вади. Якщо у вас є 2 вузли та коли у вас 64 вузли, все буде вести себе по-різному.

Мій звичайний підхід до оптимізації (виміряти, спробувати щось, перевірити правильність, виміряти відмінності, повторити) тут насправді не працює, оскільки я не можу ефективно виконати кроки 2 та 3 для важливих частин проблеми (надійність та ефективність навантаження). Цей сценарій не здається унікальним. Який загальний підхід до виконання подібних завдань у таких умовах?

Є кілька пов'язаних питань:

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

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

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

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

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

• Оскільки ви не можете все перевірити заздалегідь, очікуйте, що проблеми з’являться у виробництві. Таким чином, спробуйте підготувати дійсно хорошу резервну стратегію при впровадженні нового коду у виробництво. Коли ваш новий код може загрожувати повільніше, ніж старе рішення, або якщо він має загрозу збоїв, переконайтеся, що ви можете перейти на попередню версію якнайшвидше. Якщо це ризикує знищити виробничі дані, переконайтеся, що у вас є хороша резервна копія / відновлення. І переконайтеся, що ви виявляєте подібні збої, додаючи якийсь механізм перевірки у вашу систему.

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

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

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

Отже, що ти можеш зробити?

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

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

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

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

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

Я б запропонував експерименти.

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

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