Як пояснити інфраструктурні витрати Spike в англійській мові
Вивчайте англійську лексику і фрази, необхідні для пояснення раптового підвищення вартості хмарної інфраструктури фінансовому та інженерному керівництву.
Пік вартості інфраструктури приземляється на столі інженера як неприємний сюрприз від фінансів, і пояснення цього добре вимагає перекладу хмарних розрахункових рядків на просту бізнес-мову, а також бути чесним про те, чого можна уникнути, порівняно з тим, що було необхідним компромісом. Цей набір слів містить слова, які використовуються у цій розмові.
Ключовий словник
** Аномалія вартості ** — раптове, несподіване відхилення від звичайних схем витрат на певну службу або ресурс, яке зазвичай виявляється за допомогою попередження про розрахунок або інструменту виявлення аномалій. “Попередження про аномалію вартості повідомило про 300-відсотковий стрибок у нашому рахунку за перенесення даних, починаючи з минулого вівторка, задовго до того, як фінанси помітили це на рахунку.”
** Вартість виходу ** — плата за дані, що залишають мережу постачальника хмарних послуг, часто найменш видимий елемент рядка, доки зміна навантаження не призведе до несподіваного збільшення кількості даних, що перетинають цю межу. “Ця пік майже повністю є витратою на вихід — ми почали реплікувати журнали до стороннього інструмента в іншому регіоні, і ніхто не позначав вартість трансферу між регіонами заздалегідь.”
** Розширення ресурсів ** — поступове накопичення невикористовуваних або забутих хмарних ресурсів (осиротілих томів, неактивних екземплярів, неприєднаних IP- адрес), які продовжують нести витрати, не надаючи жодної цінності. “Частина цього зростання - це розкидання ресурсів - ми знайшли десяток осиротілих томів з проекту, який був виведений з експлуатації кілька місяців тому, але так і не був очищений.”
** Правильне розміщення ** — процес зміни розміру ресурсу (тип екземпляра, рівень зберігання, пам’ ять) відповідно до його фактичного використання, а не розміру, який було обрано оборонно або звичкою. “Відповідне розміщення цього екземпляра бази даних повинно зменшити його щомісячну вартість на сорок відсотків — на даний момент він призначений для максимального навантаження, яке він майже ніколи не досягає.”
** Зарезервована потужність (знижка за зобов’ язанням) ** — модель ціноутворення, де зобов’ язання до певного рівня використання заздалегідь, на фіксовану дату, приносить значну знижку порівняно з ціноутворенням на запит. “Якщо базове використання цього навантаження залишається стабільним, перехід на резервовану потужність замість ціноутворення за запитом зменшить ці конкретні витрати приблизно на третину.”
Пояснення кореневої причини
- «Ця пік не від більшого клієнта трафіку - це майже повністю вихідна вартість від нового крос-регіонального завдання реплікації, яке ми додали в останньому спринті»
- Близько третини цього зростання є розкиданням ресурсів — сиротські ресурси з виведених з експлуатації проектів, які ніколи не були фактично очищені
- “Детектор аномалії витрат виявив це за три дні до того, як був би випущений рахунок, що обмежив збитки до тижня непотрібних витрат.”
Що потрібно змінити?
- «Я хочу негайно правильно розмістити цей екземпляр — він призначений для шаблону пікового навантаження, який не існував з тих пір, як ми змінили архітектуру шість місяців тому»
- «Давайте встановимо автоматичне очищення для сирітських ресурсів, щоб цей вид розширення не накопичувався безмовно між аудитами»
- «Якщо використання цього навантаження залишається передбачуваним, я рекомендую пересунути його на зарезервовані можливості, щоб заблокувати нижчу швидкість в майбутньому»
Перевірка спільного виправлення
- «Чи можемо ми підтвердити, що законопроект наступного місяця відображає правильні зміни розмірів, перш ніж ми розглянемо це вирішення?»
- «Давайте встановимо попередження про аномалію вартості на цей конкретний пункт лінії, щоб ми впіймали наступний несподіваний стрибок за кілька днів, а не в кінці циклу розрахунку»
- «Якщо витрати на вихід знову піднімаються, давайте перевіримо, чи це те саме завдання реплікації або нове джерело, перш ніж припустити, що це та ж сама коренева причина»
Професійні поради
- ** Переклад термінів хмарного розрахунку на причину і наслідок. ** Сказати « це вихідна вартість від реплікації між регіонами » набагато більш дійсно для фінансового учасника, ніж вказувати на непояснений рядок на рахунку.
- ** Відокремити небажані відходи від необхідних компромісів. ** Ясно відрізняти “розповсюдження ресурсів, яке ми повинні прибрати” від “навмисного рішення архітектури з компромісом вартості” запобігає лідерству від прийняття кожного збільшення вартості як помилки.
- ** Завжди поєднуйте пояснення кореневої причини з перспективним виправленням. ** Пояснення того, чому відбувся пік без запропонованого правильного розміру, резервованої потужності або очищення, залишає зацікавлених осіб у захопленні, чи просто це повториться наступного місяця.
Практичні вправи
- Напишіть два речення, що пояснюють підвищення вартості для нетехнічної сторони, відрізняючи навмисне обмеження архітектури від випадкового розширення ресурсів.
- Опишемо в одному реченні різницю між правим розміщенням і переходом на резервовані можливості як стратегії зменшення витрат.
- Створити коротке повідомлення з пропозицією налаштувати попередження про аномалію вартості у певній службі після несподіваного підвищення.
Навигація Nuance: Phrasing for International Teams (англійською)
Пояснення складних технічних питань, таких як несподіване зростання вартості інфраструктури, завжди є викликом, але при спілкуванні з колегами з різних сфер діяльності - особливо з тими, хто все ще розвиває свою професійну англійську - потенціал для нерозуміння значно зростає. Це не просто про передачу * того, що * сталося; це про те, щоб зробити це в такий спосіб, який є ясним, шанобливим і уникаючи жаргону, який може бути незнайомим. Розглянемо деякі конкретні фрази і підходи, які можуть зменшити цей проміжок.
Однією з поширених пасток є використання надто технічної мови без контексту. Замість того, щоб сказати «Група автомасштабування екземплярів EC2 спричинила значне збільшення витрат через збільшення трафіку», спробуйте щось на зразок: «Ми спостерігали помітне зростання наших витрат на хмару, в основному збільшення попиту на обчислювальні ресурси. Це призвело до того, що у будь- який момент часу було активним більше екземплярів. » Ключовим є переклад технічних термінів на легко зрозумілі описи. Іншим корисним методом є обґрунтування проблеми навколо впливу - що * відбувається * через збільшення витрат? “Це призвело до більшого рахунку, ніж очікувалося, що ми повинні розслідувати і негайно вирішити”
Крім того, будьте обережні з фразами, що вказують на звинувачення. Навіть якщо ситуація виникає через неправильну конфігурацію або нехтування метрикою, підхід до неї з тоном співпраці є життєво важливим. Фрази на кшталт «Здається, що був несподіваний стрибок активності» є м’якшими, ніж «Авто-масштабування не було належним чином налаштовано», що може відчуватися обвинувачуючим. Розглянемо такі слова: « Давайте співпрацюємо, щоб зрозуміти, що спричинило це збільшення, і переконаємося, що ми маємо правильний контроль на місці, щоб рухатися вперед. » Під час обговорення коментаря перегляду коду, наприклад, ви можете сказати: « Ця зміна ввела нову метрику, яка не була повністю врахована в наших прогнозах вартості — давайте обговоримо, як ми можемо її інтегрувати. »
Наконец, помни, что прямота не всегда лучше. Фраза на кшталт «Відсотки зросли» є тупою і не корисною. Замість цього, виберіть щось більш виміряне: «Ми виявили значне збільшення витрат на інфраструктуру, і я хотів запланувати час для обговорення факторів, що сприяють цьому, і потенційних стратегій зменшення». Це демонструє професіоналізм і створює умови для продуктивної дискусії. Практикування цих методів фразування не тільки покращить спілкування, але й сприятиме створенню більш інклюзивного та спільного середовища у вашій команді.