QFE

Открытый ключ Асимметричное шифрование основано на использовании пары связанных ключей: открытого (публичного) и закрытого (приватного). Открытый ключ доступен всем и применяется для шифрования информации, тогда как закрытый ключ хранится в строгом секрете у владельца и нужен для её расшифрования. Чтобы отправить конфиденциальное сообщение, отправитель шифрует его публичным ключом адресата. Прочесть такое послание сможет только сам получатель, так как расшифровать его обратно можно исключительно с помощью его уникального приватного ключа.

Код ошибки Это стандартный ответ сервера о результате обработки запроса. Ошибки серии 4xx указывают на то, что проблема возникла на стороне клиента, например, из-за неверного адреса или отсутствия доступа. 403 Forbidden (Запрещено) означает, что сервер получил запрос, но не может его выполнить из-за отсутствия необходимых прав. В отличие от ошибки 401 Unauthorized (Не авторизован), которая сообщает, что сервер не опознал пользователя и требует войти в систему (аутентификация), код 403 говорит о проблеме с уровнем доступа (авторизация). Простыми словами: при ошибке 401 вы не предоставили подтверждение личности, а при 403 — система вас узнала, но обнаружила, что у вашего аккаунта нет полномочий для выполнения этого действия. Это ситуация, когда доступа к ресурсу нет даже после успешного входа.

GitOps Это методология управления инфраструктурой и развертывания приложений, при которой Git используется как единственный источник правды. Вместо ручной настройки серверов или запуска разрозненных скриптов разработчики описывают желаемое состояние системы в виде кода (IaC) и сохраняют его в Git-репозитории. Специальные автоматические инструменты (например, Argo CD или Flux) непрерывно сравнивают то, что написано в Git, с тем, что реально запущено на серверах. Если обнаруживается расхождение, система автоматически обновляет инфраструктуру, чтобы она в точности соответствовала коду в репозитории. Главный плюс GitOps — это прозрачность и безопасность. Любое изменение инфраструктуры проходит через стандартный процесс код-ревью (Pull Request), а в случае аварии можно мгновенно откатить систему к любому стабильному состоянию, просто отменив последний коммит в Git.

Идемпотентность Это свойство операции, при котором её многократное повторение приводит к тому же результату, что и однократное выполнение. В контексте разработки и API это означает, что если сервер получит один и тот же запрос несколько раз, итоговое состояние системы останется таким же, как после первого успешного вызова. В архитектуре REST идемпотентными считаются методы GET, PUT и DELETE. Например, сколько бы раз вы ни отправляли запрос на удаление конкретного файла, результат будет одинаковым: файла нет. В отличие от них, метод POST не является идемпотентным, так как каждая отправка запроса может создавать новый объект в базе данных. Это свойство критически важно для надежности распределенных систем. Если из-за сбоя сети клиент не получил подтверждение и отправил запрос повторно, идемпотентность гарантирует, что система не совершит лишних действий, таких как повторное списание денег или создание дублирующего заказа. Она позволяет безопасно повторять операции до получения ответа, сохраняя целостность данных.

ACID Это набор из четырех ключевых свойств, которые гарантируют надежность и предсказуемость работы базы данных при выполнении транзакций. Этот стандарт особенно критичен для финансовых и юридических систем, где любая ошибка в данных недопустима. Аббревиатура расшифровывается так: 🤩 A — Atomicity (Атомарность): Гарантирует, что транзакция будет выполнена полностью или не выполнена совсем. Если хотя бы одна операция внутри транзакции сорвется, вся цепочка изменений «откатывается» к исходному состоянию. Принцип «всё или ничего». 🤩 C — Consistency (Согласованность): Обеспечивает переход базы из одного валидного состояния в другое. База данных проверяет все правила и ограничения (например, баланс не может быть отрицательным), и если транзакция их нарушает, она не будет зафиксирована. 🤩 I — Isolation (Изолированность): Позволяет параллельным транзакциям не мешать друг другу. Пока одна транзакция не завершена, другие процессы не должны видеть её промежуточные результаты. Это создает иллюзию, что транзакции выполняются строго по очереди. 🤩 D — Durability (Долговечность): Гарантирует, что если система подтвердила успех транзакции, данные будут сохранены навсегда. Даже если сразу после подтверждения произойдет сбой питания или упадет сервер, после перезагрузки данные останутся в базе. Простыми словами, ACID превращает хаос одновременных запросов в строгую и безопасную систему, где данные никогда не «повиснут» в неопределенном состоянии.

Stateless Правильный ответ — второй, так как принцип Stateless подразумевает, что сервер не хранит информацию о текущей сессии пользователя между отдельными вызовами, и каждый запрос обрабатывается независимо. Первый вариант может показаться верным из-за буквальной трактовки термина «без состояния», однако он ошибочен. Ограничение Stateless касается только состояния сессии — временной «памяти» сервера о том, что конкретный пользователь делал секунду назад. В традиционных (stateful) системах сервер выделяет кусок оперативной памяти под объект сессии, где хранит, например, статус авторизации или этап заполнения многостраничной анкеты. Это привязывает клиента к конкретному серверу: если следующий запрос попадет на другой узел кластера, тот «не узнает» пользователя, так как в его локальной памяти этой сессии нет. В архитектуре REST серверу не запрещено обращаться к базам данных для хранения или получения постоянной информации (состояния ресурсов). Однако он не должен удерживать в своей оперативной памяти промежуточный контекст взаимодействия. Каждый запрос от клиента должен быть самодостаточным — то есть содержать все необходимые данные (токены, ID, параметры) для его полной обработки. Именно это позволяет системе легко масштабироваться: любой свободный сервер может обработать любой входящий запрос, не полагаясь на историю предыдущих обращений.

Hard course Я придумала курс, который может сломать любого писателя :) Я не специально. Просто мне идея показалась интересной. Идея курса в том, чтобы написать четыре сложных гайда (в компании со мной) и научиться параллельно многому. Конечно, я буду проводить занятия и поддерживать вас на протяжении всего пути, хотя боюсь, что темы все равно будут сложными для большинства. Но давайте попробуем. 🕺 Предлагаю курс Курс состоит из четырех кейсов, связанных с облачными технологиями. На каждый кейс выделяется две недели. Каждую неделю проходит занятие с теорией и упражнениями по кейсам. Помимо этого я оставляю подробное ревью на написанные инструкции. После двух недель мы переходим к новому кейсу. Я думаю, что следующие кейсы будут особенно интересны: 1. Гайд, как запустить локальный сервер FastAPI в Docker-контейнере. Это поможет разобраться с Docker и портами. 2. Гайд по созданию S3-бакета в LocalStack. LocalStack — это эмулятор облака AWS. 3. Гайд, как подключить Node Exporter для передачи метрик Prometheus. Полезно для понимания мониторинга. 4. Гайд, как сконфигурировать MAAS так, чтобы он стал DHCP-сервером для вашей виртуальной среды. Полезно для понимания настроек bare metal. Если вам все таки интересно такое предложение, то напишите мне — @elenashliaga

Эволюция писателя Недавно мне пришла одна мысль в голову. Все технические писатели начинают работу с того, что отрабатывают свои навыки и учатся писать лучшие тексты. Учатся писать по стайлгайду и без ошибок, учатся писать идеально. А потом оказывается, что стайлгайд везде разный. Нет точного ответа на то, что такое хороший текст. А самое худшее, что с ростом грейда задачи все больше звучат уже не как понятные требования, а как в сказке — "или туда, не знаю куда, и сделай то, не знаю что". Со временем ты начинаешь понимать, что не всегда так важно написать все идеально, как важно написать побольше. Некоторые дедлайны приводят к тому, что ты сдаешь работу, а потом тратишь еще много месяцев после дедлайна, чтобы поправить ее. И я хочу сказать, что это нормально. Все хорошо, обстоятельства бывают разные, решения бывают разные. По ходу проекта придется еще много раз переделывать одно и то же, но ты сможешь и ты справишься. Потому что несмотря на все сложности, в конце ты все таки сделаешь ту самую документацию, которую ты хочешь видеть.

Брандмауэр Правильным является вариант под номером три, так как именно фильтрация и контроль сетевого трафика на основе правил безопасности составляют суть работы брандмауэра. Это решение служит защитным барьером между сетями, предотвращая несанкционированный доступ и блокируя потенциально опасные пакеты данных. В то же время первый вариант описывает работу DNS-сервера по разрешению доменных имен, второй относится к функционалу DHCP-сервера для автоматической настройки узлов, а четвертый касается систем хранения и резервного копирования. Таким образом, только третий вариант точно определяет роль межсетевого экрана в обеспечении безопасности сетевой инфраструктуры.

Правильное употребление SaaS Правильный ответ №3 описывает SaaS, поскольку он точно отражает суть модели: готовое программное обеспечение, доступное через интернет по подписке, где вся инфраструктура и обслуживание лежат на плечах провайдера. Вариант №1 неверен, так как покупка серверов и локальная установка ПО противоречит облачной природе SaaS. Вариант №2 ошибочно приписывает SaaS функции PaaS или IaaS, ведь в SaaS пользователь не управляет базами данных или операционными системами. Вариант №4 описывает установку ПО локально, что является характеристикой традиционных лицензий, а не облачного сервиса SaaS.

CAPTCHA Правильный ответ — вариант номер два, так как CAPTCHA является прямой отсылкой к знаменитому тесту Тьюринга, адаптированному для автоматической проверки в интернете. Эта аббревиатура расшифровывается как Completely Automated Public Turing test to tell Computers and Humans Apart, что буквально означает полностью автоматизированный публичный тест Тьюринга для различия компьютеров и людей. В отличие от классического теста Тьюринга, где человек пытается определить, кто перед ним — машина или личность, в случае с капчей именно программный алгоритм на стороне сервера выступает в роли экзаменатора. С технической точки зрения этот механизм работает на прикладном уровне (OSI Layer 7), защищая веб-ресурсы от автоматизированных спам-ботов, брутфорс-атак и нежелательного трафика. Остальные варианты ответа являются вымышленными и не имеют отношения к реальной истории возникновения этой технологии.