QFE

Для чего используется команда git cherry-pick?

Liveness Probe Пробы — отличный способ следить за работой приложения. Самое интересное — это то, как они работают. В приложении разработчик может предусмотреть API эндпоинт, через который Kubernetes сможет проверять состояние приложения. Это проверка по HTTP. Еще Kubernetes умеет проверять состояние приложения, настраивая TCP соединение или выполняя команду в контейнере. После такой настройки в манифесте Pod Kubernetes может проверять работу приложения и перезапускать под в случае падения приложения.

Какой принцип лежит в основе Liveness-пробы (Liveness Probe) в Kubernetes?

Forward и Reverse Proxy Forward Proxy действует в интересах клиента (пользователя): он стоит перед пользователем, скрывает его реальный IP-адрес и отправляет запросы во внешний интернет от своего имени (пример: офисный VPN или корпоративный прокси). Reverse Proxy действует в интересах сервера (бэкенда): он стоит перед группой серверов, принимает все входящие запросы из интернета и сам распределяет их по внутренним узлам, скрывая настоящую архитектуру приложения (пример: Nginx, Cloudflare). Простыми словами: Forward Proxy защищает пользователя от интернета, а Reverse Proxy защищает сервер от пользователей.

В чем главное отличие Forward Proxy от Reverse Proxy?

TCP и UDP Два протокола, про которые есть миллион мемов в интернете. Протокол TCP проверяет наличие соединения перед отправкой пакетов. Про него еще говорят «трехстороннее рукопожатие». Протокол UDP же не проверяет, поэтому иногда отправка пакетов по UDP выглядит как на картинке.

В чем заключается фундаментальное отличие сетевого протокола UDP от TCP?

CI/CD (Continuous Integration / Continuous Delivery) Это подход к разработке ПО, который автоматизирует сборку, тестирование и доставку обновлений приложений. Процесс CI (непрерывная интеграция) автоматически проверяет и тестирует новый код при каждом изменении в Git, чтобы сразу находить баги. Процесс CD (непрерывная доставка) берет проверенный код и автоматически выкатывает его на рабочие сервера. Например, когда разработчик делает новую кнопку на сайте интернет-магазина и отправляет код в репозиторий, система CI/CD за пару минут сама прогоняет автотесты, собирает релиз и обновляет сайт без участия человека и без остановки сервиса. Для настройки таких процессов обычно используют инструменты GitLab CI, GitHub Actions или Jenkins.

Что означает аббревиатура CI/CD?

301 и 302 Ну люблю я вопросы про коды ответа HTTP. Коды 3xx означают, что ресурс был перемещен. 301 говорит о постоянном переносе адреса, а 302 — о временном. Правильным ответом был второй.

В чем заключается главное различие между HTTP-статусами перенаправления 301 Moved Permanently и 302 Found?

502 и 504 Опытный глаз с первого взгляда различил в этом вопросе коды ответа с проблемами на стороне сервера. Коды начинаются с 5xx. Коды 5xx означают, что запрос был отправлен, но ответ от сервера либо не пришел, либо с ним были какие-то проблемы. Осталось понять разницу между 502 Bad Gateway и 504 Gateway Timeout. Код 502 означает, что ответ пришел, но он некорректен. Код 504 означает, что за выделенное время ответ не пришел. Правильным ответом был последний.

В чем заключается главное различие между ошибками 502 Bad Gateway и 504 Gateway Timeout?

Снова про уровни OSI Возможно не все работают напрямую с OSI, но я думаю, что это отличный пример темы, когда понимание позволяет писать значительно более качественную документацию. Например, понимание разницы между балансировщиками на уровнях L7 и L4 позволяет лучше описывать взаимодействия по сети. Оба балансировщика перераспределяют трафик между серверами. В чем же разница? На транспортном уровне L4 у балансировщика есть доступ только к IP-адресам и портам. То есть он может перенаправить поток по-разному для портов 3306 и 80, но не для разных URL-адресов. На прикладном уровне L7 балансировщик может отправлять картинки на сервер server-img.local, а авторизацию — на server-auth.local. То есть балансировщик может использовать данные запроса. Правильным был второй ответ.

В чем заключается главное архитектурное отличие балансировщика нагрузки прикладного уровня (L7) от балансировщика транспортного уровня (L4)?

GraphQL Я не буду пытаться сейчас объяснить всю сложность реализации GraphQL, да это и не нужно. Я хочу донести основную идею. Основная идея состоит в том, что в случае RESTful API мы получаем от сервера изначально известные поля с известной структурой, например: user: Elena, date: 25.07.2026, occupation: technical writer Этих полей может быть слишком много или недостаточно, поэтому в GraphQL есть возможность точно указать поля, который вы хотите получить, например, user и occupation. Итог: GraohQL дает возможность программе указывать определенные поля, которые нужно получить от сервера, и получать только их. Правильным ответом был первый.

Какую основную проблему традиционных REST API решает технология GraphQL?

Git rebase и git merge Ни одна из этих команд напрямую не связана с удалением веток или подключением к сети. Так что два последних ответа были совсем не про то. Основная разница между git merge и git rebase в том, что в результате первой команды в истории основной ветки появляется один мерж коммит, а в результате второй — история ветки, то есть порядок коммитов сохраняются, и новые коммиты добавляются в конец ветки. Представим это на примере двух очередей из людей, которые держат коробки: 🤩 git merge берет одну из очередей и все коробки передает одному человеку, который становится в конец соседней очереди; 🤩 git rebase расставляет в вашей очереди людей из другой очереди в том же порядке, как они стояли в своей очереди, а потом добавляет в конец очереди людей из вашей очереди.

В чем основное отличие команды git rebase от git merge при объединении веток?

⭐️⭐️ 16 июля пройдет бесплатный онлайн-митап TechDocs Поговорим о документации с разных сторон: как создавался портал разработчиков RWB, зачем техническим писателям единая система оценки задач и можно ли построить зрелые процессы документирования, если в команде всего один техписатель. В программе: ⏹️ «Летопись документации разработчиков WB API» | Лидия Рудакова, лид команды документирования Public API. ⏹️ «Единая система оценки задач техписателей: как внедрить новый подход без боли» | Евгения Красильникова, технический писатель в команде разработки документации и методик обучения ПО. ⏹️ «100 к 1: Как организовать подход "документация как услуга" в одиночку» | Антон Гафаров, технический писатель в команде FinTech Infra. Когда: 16 июля, 16:00 Формат: онлайн ➡️ Зарегистрироваться