Інфраструктура11 тем
Інфраструктура, DevOps і хмара
Інфраструктура — це все, що перетворює код на щось працююче, за чим можна спостерігати, що можна змінювати й відкочувати. У розділі 11 тем у чотирьох групах: DevOps і пайплайн, який збирає один артефакт і просуває його незмінним; три великі хмари й те, як кожна стримує помилку; MLOps — ті самі задачі знову, але для моделі замість бінарника; і моніторинг, який робить інцидент відповідним на питання о третій ночі.

Що всередині
Кожен напрям нижче — це група тем. Відкрийте будь-який, щоб читати його сторінки.
- DevOpsПроцес, одиниця й цикл: звички злиття, шари образу та зведення стану.CI/CDDockerKubernetes
- ХмараПо одному тривкому механізму на провайдера: авторизація, межі та дві площини керування.AWSGCPAzure
- MLOpsМодель — це артефакт збірки з чотирьох входів. Решта випливає з того, щоб сприйняти це серйозно.ПайплайниСервінгВектори
- МоніторингЩо ви записуєте — і кого маєте право через це розбудити.ЛогуванняSLOЧергування
З чого почати
- Налаштовуєте доставкуСпершу CI/CD: безперервна інтеграція — це звичка щодо частоти злиття, а не сервер, який ганяє тести.
- Контейнери досі як магіяDocker пояснює, чому порядок у Dockerfile вирішує час збірки і чому контейнер — це процес, а не маленька машина.
- Обираєте чи аудіюєте хмаруТри хмарні сторінки не порівнюють каталоги сервісів. Почніть з AWS — про те, як насправді авторизується запит.
- Ніхто не знає, чи воно працюєЛогування, потім алертинг. Перше вирішує, чи матиме відповідь пізніше питання; друге — кого розбудять.
Інші розділи
- РозробкаРозробка програмного забезпечення — це робота про те, де проходять межі в системі, що працює по кожен їхній бік і чого коштуватиме зсунути одну з цих меж, коли код уже працює. У розділі 28 тем: архітектура, браузер, пʼять бекенд-середовищ, чотири мобільні платформи, мовні моделі та бази даних під усім цим. Кожна сторінка тримається на обмеженні, яке справді відрізняє варіанти, а не на поверхні API.
- QAЗабезпечення якості (QA) — це практика вирішувати, що перевіряти, запускати ці перевірки достатньо часто, щоб вони мали сенс, і розуміти, що змінюється, коли те, що тестують, перестає давати ту саму відповідь двічі. У розділі 9 тем у трьох групах: види тестування, які всі памʼятають наполовину; автоматизація на Playwright, Cypress і Selenium; і тестування продуктів на мовних моделях, де твердження стає оцінкою, а не рівністю.
Було корисно?
Поділіться з тим, хто працює над тією ж задачею.