Англійська для розробників Erlang

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

Ключовий словник

** Let it crash ** — філософія Erlang, за якою процесу дозволяється негайно завершити роботу у разі несподіваної помилки, замість того, щоб у захисному режимі ловити кожен виняток, покладаючись на супервайзера, який перезавантажить процес у стан, який вважається вірним. “Ми припинили обгортання кожного виклику в try/catch і прийняли let it crash — супервайзер перезапускає процес швидше, ніж ми могли б відновити його вручну.”

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

• “Дерево нагляду перезавантажило лише роботу, яка зазнала невдачі, тому решта програми продовжувала обслуговувати запити під час інциденту.” *

** Передача повідомлень / поштова скринька ** — механізм, за допомогою якого процеси Erlang спілкуються виключно за допомогою асинхронних повідомлень, які надсилаються до поштової скриньки кожного процесу, без спільної пам’ яті між процесами. “Оскільки немає спільного стану, усі координації відбуваються за допомогою передачі повідомлень — кожен процес просто читає з власної поштової скриньки.”

** Hot code swapping ** — здатність BEAM завантажувати нову версію модуля у запущену систему і мігрувати живі процеси до неї без зупинки вузла або втрати з’ єднань. “Ми відправили виправлення через обмін кодом, тому телекомунікаційний комутатор ніколи не відключався під час розгортання.”

** Ізоляція процесів ** — гарантія того, що кожен легкий процес Erlang має свою власну пам’ ять і збірник сміття, отже аварія або перевантаження пам’ яті у одному процесі не може пошкодити або заблокувати інший процес. “Ізоляція процесів є причиною того, чому один обробник з’ єднань, що неправильно поводиться, не знижує інші десять тисяч з’ єднань на вузлі.”

Звичайні фрази

• Чи слід з цією помилкою поводитися оборонно, чи це випадки, коли ми просто дозволяємо їй зламатися?»
• Яка стратегія перезапуску для цієї гілки дерева нагляду — один-за-одного або один-за-всіх?
• Чи координується цей стан через передачу повідомлень, чи ми випадково щось ділимося?»
• Чи можемо ми відправити цю поправку з обміном гарячим кодом, або чи вимагає вона повного перезапуску вузла?
• «Чи ми насправді покладаємося на ізоляцію процесів тут, чи ми ввели спільний ресурс?»

Приклади висловлювань

Пояснення рішення щодо дизайну колегі:

• “Ми навмисно дозволили йому зламатися через неправильно сформований пакет замість того, щоб намагатися розібратися з ним — дерево контролю займається відновленням.” *

Перегляд інциденту після смерті:

• “Ізоляція процесу містила помилку у одному обробнику з’ єднань, саме тому відключення вплинуло лише на одного клієнта, а не на весь вузол.” *

Опис стратегії розгортання:

• “Гарячий обмін кодів дозволяє нам лагодити модуль розрахунків в робочі години, не залишаючи жодного активного дзвінка.” *

Професійні поради

• Поясніть, що ** let it crash ** є стратегією, а не недбалістю — вона працює лише завдяки дереву контролю, яке стоїть за нею, отже, завжди згадуйте обидва разом.
• Використовуйте ** supervision tree ** під час обговорення радіусу взривів аварій — надання назви стратегії перезапуску (один- за- один проти один- за- всіх) показує, що ви розумієте, що таке збереження, а не просто відновлення.
• Досягнення ** повідомлення передачі ** коли хтось вважає, що Erlang має спільний змінний стан — це найшвидший спосіб виправити поширене неправильне уявлення про потокові фони.
• Згадуйте ** Hot Code Swapping ** обережно в інтерв’ю - це справжній диференціатор BEAM, але будьте готові пояснити його операційні ризики, а не тільки його переваги.

Практичні вправи

1. Поясніть філософію «нехай він звалиться» і чому вона залежить від добре розробленого дерева контролю, щоб бути безпечною.
2. Описати, як передавання повідомлень і ізоляція процесів разом виключають цілу категорію помилок одночасності.
3. Напишіть два речення, які описують ситуацію, у якій обмін кодом під час роботи буде корисним.

На практиці: Навігація нюансів в спільному розвитку

Багато розробників, які не знають Erlang, особливо ті, хто переходить з мов з більш жорсткою обробкою помилок або постійним моніторингом, знаходять філософію «нехай це звалиться» глибоко незручним. Це основна ідея віртуальної машини BEAM і дизайну Erlang, побудованого навколо стійкості і ефективного використання ресурсів. Однак, простого зауваження «він повинен зламатися» недостатньо в англомовному професійному середовищі; вам потрібно сформулювати * чому * цей вибір зроблений, демонструючи розуміння основних принципів і зменшуючи потенційні проблеми. Це часто включає в себе пояснення компромісів - жертвуючи негайною видимістю для більшої загальної стабільності системи.

Розглянемо сценарій: Аліса щойно переглянула PR Боба, який вводить нову службу для обробки автентифікації користувача. Сам код здається функціональним, але Боб коментує: « Потрібно більш надійне оброблення помилок ». Хоча цей коментар має добрі наміри, він не є особливо корисним. Краще відповідь - і така, що демонструє словниковий запас, який ми обговорювали - була б: “Я ціную ваш фокус на міцності. Я переглянув службу автентифікації і навмисно обрав підхід « дозволити аварію » у певних сценаріях невдач. Метою є уникнення небажаного навантаження на процес під час перехідних помилок, таких як перевищення часу очікування мережею. Дозволяючи поширення помилок, система може швидко відновлюватися і продовжувати обслуговувати законні запити. Ми впровадили автоматичні вимкнення, щоб запобігти каскадним збоям, а журнали налаштовані на зберігання докладної інформації для зневадження, коли це необхідно. Цей дизайн відповідає філософії Erlang щодо мінімізації споживання ресурсів у випадку періодичних проблем. ” Зауважте, як ця відповідь пояснює * чому * аварія прийнятна – це не випадкове рішення, а ретельно обдумане рішення, засноване на продуктивності і стійкості.

Крім того, чітке спілкування є важливим під час перегляду коду або при описі змін в Pull Requests. Замість того, щоб сказати « Функція тепер буде обробляти помилки », що не є достатньо точним, ви можете написати: « Це оновлення змінює обробку помилок, щоб дати перевагу негайному відновленню. Незафіксованим виняткам дозволяється поширюватися вгору; це дозволяє швидше виявити і ізолювати проблеми, а не намагатися безмовно проковтнути їх, що могло б приховати основні проблеми. “Ця фраза підкреслює активну природу зміни - навмисний вибір прийняти невдачу як можливість для діагностики. Це також ненадовго підкреслює цінність філософії дизайну Erlang.

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

Ось приклад, який показує, як ефективно вести журнал помилок:

-module(my_service).
-export([start/1]).

start(Config) ->
  case system_info(os_type) of
    linux ->
      {ok, Logger} = logger:new({my_service, "error"}, []),
      logger:set_level(Logger, error);
    _ ->
      % Handle other OS types here (e.g., windows, darwin)
      io:format("Warning: Unsupported OS type ~p~n", [system_info(os_type)]).
  end,

  {ok, true}.