MiddlePython Developer > Основы Python > Asyncio и асинхронность
Короткий ответ asyncio.gather запускает все переданные корутины конкурентно и ждёт завершения всех, так что суммарное время определяется самой долгой задачей; последовательный await выполняет их одну за другой, и суммарное время равно сумме времён всех задач. Как это работает подробнее await coro1(); await coro2() сначала полностью завершает coro1, и только затем начинает coro2 — конкурентности нет. asyncio.gather(coro1(), coro2()) оборачивает обе в задачи и позволяет event loop переключаться между ними, так что их ожидания перекрываются по времени. Пример кода Что использовать на практике Практика. gather полезен для нескольких независимых I/O-bound операций; нужно аккуратно обрабатывать исключения — по умолчанию gather прерывается при первом исключении, если не передан return_exceptions=True. Подводные камни Риски. Используют последовательные await там, где задачи независимы, упуская возможность ускорения; забывают про return_exceptions=True, когда нужно собрать результаты всех задач независимо от того, упа
asynciocoroutines
JuniorJava Developer > Java Core > Исключения Короткий ответ Разница — в том, проверяет ли исключение компилятор. Checked-исключения проверяются на этапе компиляции: их нужно обработать в try-catch или объявить в throws, иначе код не соберётся. Unchecked-исключения (RuntimeException и её наследники, а также Error) компилятор не проверяет: они возникают в рантайме, и обрабатывать их не обязательно. Как это работает подробнее Checked-исключения — подклассы Exception, кроме RuntimeException: IOException, SQLException, ClassNotFoundException, InterruptedException и другие. Они обычно сигнализируют о проблемах внешней среды (файл не найден, сеть недоступна), поэтому язык заставляет разработчика обрабатывать их явно. Unchecked-исключения — RuntimeException и все её наследники (NullPointerException, ArithmeticException, ArrayIndexOutOfBoundsException, NumberFormatException, ClassCastException), а также Error и его наследники. Они, как правило, означают ошибки логики или программиста: обработка и объявление в throws не обязательны. Пример кода Что использовать н
checked-exceptionsexceptions
JuniorDevOps Engineer > Контейнеры и доставка > Kubernetes и оркестрация Короткий ответ Deployment — это декларативный контроллер, который через ReplicaSet поддерживает заданное число реплик Pod, пересоздаёт их при сбоях и управляет обновлениями версии приложения; одиночный Pod такого самовосстановления не имеет. Как это работает подробнее Deployment описывает желаемое состояние (образ, число реплик, стратегию обновления), а контроллер в control plane постоянно сверяет фактическое состояние с желаемым и создаёт/удаляет Pod через ReplicaSet, чтобы их совпасть. Пример кода Что использовать на практике Практика. Deployment используют для stateless-приложений, которым не важны порядок запуска и устойчивые идентификаторы. Обновление образа через kubectl set image или изменение манифеста запускает rolling update по заданной стратегии, а при проблеме можно откатиться командой kubectl rollout undo. Подводные камни Риски. создавать "голый" Pod в проде и удивляться, что после падения узла он не восстанавливается; редактировать Pod, созданный Deployment'ом, напрямую — изменения будут перезап
deploymentkubernetes
JuniorDevOps Engineer > Контейнеры и доставка > Скриптинг и автоматизация Короткий ответ git merge создаёт новый merge-коммит, сохраняя историю обеих веток как есть, а git rebase переносит коммиты фиче-ветки поверх новой базовой точки, переписывая их хэши и создавая линейную историю; rebase не стоит применять к веткам, которые уже видели другие разработчики и могут быть у них локально. Как это работает подробнее merge находит общего предка двух веток и объединяет изменения одним коммитом с двумя родителями; rebase же пересоздаёт каждый коммит фиче-ветки заново, как будто он был сделан поверх текущего состояния целевой ветки, из-за чего у коммитов меняются хэши. Пример кода Что использовать на практике Рекомендация. для личной, ещё не запушенной или запушенной только в свой форк ветки rebase даёт чистую линейную историю перед мерджем в main. Для уже опубликованной общей ветки, над которой работают несколько человек, предпочтительнее merge, чтобы не переписывать историю, которую кто-то уже вытянул к себе. Подводные камни Ошибка. делать rebase над веткой, которая уже запушена и исполь
branchinggit
JuniorPython Developer > Основы Python > HTTP-семантика Короткий ответ GET запрашивает представление ресурса и не должен менять состояние сервера, параметры передаются в URL; POST отправляет данные для создания ресурса или выполнения действия и обычно изменяет состояние, данные идут в теле запроса. Как это работает подробнее GET — безопасный (safe) и идемпотентный метод: повторный вызов с теми же параметрами не меняет данные и возвращает тот же результат (если данные не поменялись извне). POST не является ни безопасным, ни идемпотентным по умолчанию — два одинаковых POST-запроса могут создать два разных ресурса. Пример кода Что использовать на практике Рекомендация. GET используют для получения списков, карточек объектов, поиска с фильтрами через query-параметры. POST — для создания ресурса, отправки форм, выполнения операций без естественного ресурса (например, /login, /orders/{id}/cancel). GET-запросы можно кэшировать, POST — как правило нет. Подводные камни Риски. передавать в GET чувствительные данные в query-параметрах (логируются серверами и проксями); испол
gethttp
JuniorDevOps Engineer > Контейнеры и доставка > Облачные платформы Короткий ответ Пользователь — постоянная идентичность с долгоживущими учётными данными, привязанная к человеку или сервису; роль — набор разрешений, который можно временно «принять» (assume), получив краткоживущие токены без хранения постоянных секретов. Роль предпочтительнее везде, где это возможно. Как это работает подробнее при назначении политики пользователю разрешения привязаны к его постоянным учётным данным; при assume role выдаются временные токены (обычно на 15 минут — несколько часов), которые автоматически истекают. Пример кода Что использовать на практике Рекомендация. для людей используют SSO/федерацию с временными ролями вместо постоянных IAM-пользователей; для приложений на виртуальных машинах/контейнерах — привязку роли к инстансу/сервис-аккаунту, а не хранение ключей в коде или переменных окружения. Проверка. get-caller-identity должен показывать assumed-role, а не IAM user, а токены должны обновляться автоматически без участия приложения. Подводные камни Риск. создавать IAM-пользователя с д
access-keyscloud-security
MiddleData Analyst > SQL и данные > SQL Короткий ответ ROW_NUMBER() всегда присваивает уникальные последовательные номера даже при равных значениях, RANK() даёт одинаковый ранг «ничьим», но пропускает следующие номера, а DENSE_RANK() даёт одинаковый ранг «ничьим» без пропусков в нумерации. Как это работает подробнее все три функции работают над окном, заданным PARTITION BY/ORDER BY. При трёх строках с одинаковым значением на 2-й позиции: ROW_NUMBER() даст 1,2,3,4 произвольно (в зависимости от порядка «ничьих», который без дополнительного критерия сортировки недетерминирован); RANK() даст 1,2,2,4 (пропускает 3); DENSE_RANK() даст 1,2,2,3. Пример кода Что использовать на практике выбор функции зависит от задачи: для «каждому ряду — свой уникальный номер» (например, для дедупликации или пагинации) нужен ROW_NUMBER(); для «официального» рейтинга, где важно показать настоящее место с учётом ничьих (как в спорте), — RANK(); для рейтинга без «дырок» в номерах — DENSE_RANK(). Если два заказа имеют одинаковую максимальную сумму, rnk у обоих будет 1, у drnk
dense-rankrank
JuniorDevOps Engineer > Контейнеры и доставка > Безопасность и DevSecOps Короткий ответ Kubernetes Secret хранит конфиденциальные данные отдельно от ConfigMap и ограничивает доступ через RBAC, но по умолчанию значение закодировано только в base64 — это кодирование для удобства передачи, а не шифрование, и без дополнительных мер (encryption at rest) секрет читается в открытом виде. Как это работает подробнее ConfigMap и Secret имеют одинаковую структуру (пары ключ-значение), но Secret предполагает более строгие ограничения доступа через RBAC и не выводится полностью в некоторых командах kubectl describe. Однако сами данные в etcd по умолчанию хранятся в base64, что легко декодируется (base64 -d) любым, кто получил доступ к объекту или к etcd. Пример кода Что использовать на практике Практика. для реальной защиты включают encryption at rest для etcd (EncryptionConfiguration), ограничивают RBAC на чтение Secret, используют внешние системы управления секретами (Vault, External Secrets Operator) для хранения и инжекта значений, а не хранят чувствительные данные напрямую в манифестах. П
configmapencryption
JuniorDevOps Engineer > Контейнеры и доставка > Kubernetes и оркестрация Короткий ответ Secret предназначен для чувствительных данных (пароли, токены, сертификаты) и по умолчанию хранится в etcd в кодировке base64 (это не шифрование), но Kubernetes ограничивает его отображение в kubectl get и поддерживает шифрование at rest при соответствующей настройке кластера, чего ConfigMap не предусматривает. Как это работает подробнее значения Secret кодируются в base64 при хранении в манифесте, но это лишь способ представления бинарных данных в YAML, а не защита — любой, кто имеет доступ к etcd или право на чтение Secret через API, может декодировать значение. Реальная защита обеспечивается RBAC-ограничениями на чтение Secret и опциональным шифрованием etcd at rest (encryption provider). Пример кода Что использовать на практике Практика. Secret монтируют как файлы или переменные окружения аналогично ConfigMap; для продакшена часто используют внешние системы управления секретами (Vault, облачные Secret Manager) с синхронизацией в Kubernetes Secret через оператор, чтобы не хранить настоящие с
configmapconfiguration
JuniorDevOps Engineer > Контейнеры и доставка > Мониторинг, логирование и observability Короткий ответ SLI (Service Level Indicator) — измеримый показатель качества (например, доля успешных запросов); SLO (Service Level Objective) — внутренняя цель по этому показателю (например, "99.9% запросов успешны за 30 дней"); SLA (Service Level Agreement) — формальное соглашение с внешней стороной, обычно включающее последствия (компенсацию) за невыполнение. Как это работает подробнее сначала выбирают SLI — конкретную метрику, которая отражает опыт пользователя (latency, доля ошибок, доступность). Затем на основе SLI формулируют SLO — целевой порог, который команда обязуется поддерживать внутри себя. SLA обычно шире и формальнее: это договор с клиентом, часто с санкциями (возврат денег, кредиты) при невыполнении, и SLA-порог обычно мягче внутреннего SLO, чтобы оставался запас. Пример кода Что использовать на практике Практика. команды используют SLO для принятия решений — например, если error budget (допустимый остаток "неудачи" по SLO) истрачен, замораживают рискованные релизы и фокусируются на надёжност
monitoringobservability