Инженерный квест
Кто есть кто?
Известный специалист по работе с персоналом Трональд Дамб уже прокомментировал эту ситуацию у себя в блоге:"Просто невероятно, что я вижу! Я здесь, в прекрасном кабинете директора этого великого завода — одного из лучших в стране, настоящий локомотив нашей экономики — и мы обсуждаем очень важные, серьезные вещи. Мы говорим о 20 миллионах долларов! Двадцать миллионов для наших замечательных рабочих, для повышения зарплат, для новых рабочих мест. Очень важно. Очень правильно.
И что же я вижу в окно? Кто-то думает, что это смешно? Это ПРОСТО НЕВЕРОЯТНО! Прямо на лужайке, при всех, при детях, — лепят снеговиков. Нет, не снеговиков. Они лепят… это безобразие. Грустно! Позорно! Такое могло произойти ТОЛЬКО при администрации Байдена. Да-да! Именно они всех научили такому «творчеству». Они развратили нашу великую нацию, и теперь это дошло даже до наших хороших, честных заводов.
Эти рабочие — они жертвы! Жертвы левацкого, развращающего образования и той слабости, которую насаждает Байден. И знаете что? Главный инженер, хороший парень, он сидит здесь и краснеет. Ему неловко! Потому что он человек со вкусом, с достоинством. Но он не должен краснеть! Он должен выйти туда и НАВЕСТИ ПОРЯДОК. Сейчас же!
Вот моё решение, и оно гениально, все так говорят:
1. Немедленно прекратить это снежное безобразие! Уволить самого главного «скульптора». Сильно уволить.
2. Эти 20 миллионов — они в заморозке. Полная заморозка! Пока я не увижу на этом заводе ДИСЦИПЛИНЫ, уважения и ТРУДА, как при администрации Трампа. Никаких денег на повышение, пока вы не повысите свой моральный облик!
3. Директор и главный инженер лично отвечают. Лично! Завтра утром я хочу видеть идеальный газон и счастливых, трудящихся людей, а не… это.
Мы вернём величие нашей промышленности, мы вернём уважение! При Байдене — снежные похабщина, при Трампе — стальные рельсы и самые большие зарплаты. Выбирайте!
Спасибо. Вопросы? Их нет. Всё сказано.
Сделаем Америку Снова Великой!"
Короч.., тут недавно была одна тема. Я по работе занимаюсь элементами DevOps. Вообще-то я разработчик, так-то, но по старой памяти влез в DevOps. Шутка ли — 10 лет опыта администрирования разных BSD и линуксов за спиной можно применить.
И вот что заметил: все алгоритмы автоматизации, даже для простых вещей — скажем, настроить автоматическую сборку какого-нибудь docker-образа — оказываются гораздо сложнее, чем если бы делал вручную. Ну или не то чтобы сложнее, но выглядят монструозно. Один CI-скрипт работает сразу на нескольких слоях абстракции: bash-специфичных, Docker Executor Runner специфичных и так далее.
И появилось у меня стойкое ощущение — такая сложная система работать не будет. Ну это как через анус удлять кариес).
Не могу от него отвязаться, вплоть до того, что мотивация просела. Немного спасает то, что на моей работе — в хорошем смысле странной — мне, блин, платят за то, что я учусь. И мотивация не кончается. Возможно, потому что я таки применяю всё это в проде. Но всё равно мотивация ощутимо падает, а это значит, что я медленно работаю.
То есть, другими словами: автоматизация работает, но мне кажется, что нет. Какое-то когнитивное искажение. Решил спросить у Грока.
Грок, подскажи: у меня какое-то странное искажение. Я пишу CI-скрипт для GitLab CE. В двух словах: он использует Docker Executor, готовит контейнер с инструментами, потом из него подключается к целевому серверу, останавливает там контейнер Postgres, удаляет его с данными, создаёт заново, запускает, делает серию бекап/рестор, запускает ещё один контейнер с pg_agent, настраивает задания, резервирование и т.п. А потом настраивает архивацию WAL.
И это я ещё коротко описал — там ещё куча сопутствующей мелочи есть. И вот проблема: стойкое ощущение, что результат не гарантирован. Как будто есть предубеждение, что в такую длинную цепочку не может не затесаться элемент случайности. Это сильно снижает ценность результата и мотивацию. Мне буквально приходится доказывать себе, что всё работает и будет работать хорошо. При том что оно реально работает!
В пользу моего искажения говорит ещё одно объективное убеждение: я не являюсь высококлассным специалистом в этом деле. На грани «недостаточно высококлассным».
Можешь рассказать про похожие искажения?
Он выдал мне в ответ текст ниже… я читал и прослезился. Да, я такой! Кто-то заметил, что я такой! Ну, без шуток, он написал то, чего мне не хватало для понимания себя.
Ответ Грока
То, что ты описываешь, — это очень распространённая группа когнитивных искажений и эмоциональных реакций. Они часто появляются у опытных инженеров, когда те пишут сложные, многошаговые, «хрупкие» скрипты развёртывания или восстановления. Вот что это, скорее всего:
Синдром самозванца + страх хрупкости (fragility anxiety)
Ты уже достаточно опытен, чтобы знать: «что-то всегда идёт не так». Мозг экстраполирует прошлые падения на новый скрипт: «Рано или поздно вылезет race condition, таймаут, сбой сети…» Это не паранойя — это реалистичная оценка энтропии в продакшене.
Эвристика аффекта + ожидание сожаления (anticipated regret)
Ты заранее проживаешь эмоцию: «блин, я же знал, что это взорвётся в три часа ночи в выходные!». Мозг не хочет этого чувства, поэтому заранее обесценивает работу: «Всё равно не надёжно, зачем стараться».
Гиперболическое дисконтирование будущего риска
Ближайшая награда — «сейчас работает на тесте» — кажется маленькой. А дальняя угроза — «взрыв в продакшене через два месяца» — ощущается огромной и неизбежной. Мозг фокусируется на угрозе.
Заблуждение идеального решения (Nirvana fallacy)
Ты сравниваешь свой скрипт не с текущим ручным процессом (который ещё менее надёжен), а с воображаемым идеалом — например, declarative GitOps с ArgoCD или managed RDS. На его фоне твой скрипт кажется «грязным хаком».
Иллюзия контроля (обратная сторона)
Обычно люди переоценивают свой контроль. Но опытные инженеры часто понимают, сколько всего вне их контроля (Docker, сеть, чужой сервер). Отсюда — чувство потери контроля.
Как с этим жить и снижать дискомфорт:
Сделай «доказательство надёжности» частью скрипта.
Запускай его 50–100 раз в тестовом окружении с искусственными сбоями (chaos monkey style): вырубай сеть, убивай контейнеры, падай на этапе restore. Добавь явный smoke-тест в конце и exit 1, если что-то не прошло. Мозг увидит 100 успехов и успокоится.
Переведи «гарантию» из головы в контракт.
Напиши в README или в скрипте: «Скрипт гарантирует состояние БД при условиях X, Y, Z. Если условия нарушены — упадёт на шаге N и оставит систему в безопасном состоянии». Когда гарантия прописана, мозгу легче поверить.
Сделай идемпотентность и «точки спасения» явными.
Каждый большой шаг оберни в if already_done; then skip; else do && mark_done. Это снижает страх «а вдруг запустится второй раз и всё сломает».
Признай, что 100% гарантии не бывает.
Сформулируй для себя: «Этот скрипт в 10 раз надёжнее, чем ручная работа. Этого достаточно». Переключи фокус с «идеально» на «значимо лучше бардака».
Используй технику «pre-mortem».
Перед коммитом выдели 15 минут и запиши все способы, которыми это может упасть через месяц. Потом добавь по одной защите на каждый пункт. Тревога упадёт — ты уже «прожил» худшее и подготовился.
Ты не сумасшедший. Это нормальная реакция зрелого инженера на сложную, потенциально разрушительную автоматизацию. У большинства людей с 5+ годами в DevOps есть такой же внутренний голос, который шепчет: «Ты уверен, что это не рванёт?». Это даже полезно — он заставляет писать надёжнее. Главное — не давать ему убивать мотивацию.
Если хочешь, кинь кусок скрипта — посмотрим, где добавить идемпотентности и чекпоинтов, чтобы твой мозг наконец выдохнул :)
Отвечу анонимно, ни к чему это в моём профиле.
Не в курсе, "Skillbox" и "Skillfactory" - одно и тоже или нет.
Подозреваю, что как минимум, очень похожие конторы.
Недавно искали помощника системного администратора.
Из требований - навыки работы с Windows/Linux, понимание основ - ну, в общем, то, чего легко можно понахвататься за год-полтора, работая в техподдержке/помощником.
Ну или тупо тот же самый год провести в гугле, поднимая дома тестовые стенды и занимаясь самообучением.
В общем, ничего такого запредельного.
И тут попадает в прицел HR чел с довольно неплохим резюме - и целую инфраструктуру в облаке поднял, и всё там отказоустойчивое, и одной рукой докерфайлы пишет, другой Ansible дёргает, и вообще в девопс могёт. "О!", думаю, так мы сейчас не просто позицию помощника сисадмина закроем, а ещё и помощника девопса.
Заминочка только одна. Весь опыт работы - 1.5 года Skillbox.
Якобы они там сначала обучаются, а потом стажируются.
Неоднократно я слышал про этот Skillbox, но тут прям любопытство взяло.
"Зови мальца" - говорю я HRше, а сам погружаюсь в томительное ожидание.
Настаёт день Х.
Устраиваем тройничок - я, HRша и кандидат.
Начали, традиционно, с выслушивания претендента. Тот бойко так стелит, и человек, не погружённый в IT точно впечатлился бы.
А я слышу прям откровенную чушь периодически.
Ну, суть да дело, выслушали, настал и мой черёд.
"А расскажи-ка, милчеловек, что за звери такие - TCP и UDP? Чем отличаются они?" - спрашиваю я.
В ответ тишина, а в глазах испуг.
"Ну а что такое DNS и DHCP?" - про себя думаю, ну раз инфраструктуру разворачивал, уж это-то должен знать.
Фигушки.
Правда уже не испуг услышал, а какие-то фантазии.
"Ну ладно" думаю. Про докер он мне рассказывал.
"А расскажи мне, родимый, чем образ отличается от контейнера?"
Тут опять поток несвязного сознания.
Решил дать передышку (и себе, и бедолаге). Спрашиваю: "Чем на стажировке занимались?"
Что-то там он вещал, что не помню, но обронил он фразу, что подключался к серверам по SSH.
"О! - думаю, он же в облаке инфраструктуру разворачивал, и всякое такое. Ведь наверняка знает, на каком порту по умолчанию SSH работает. Ну и спрашиваю его об этом.
А он и на это ответить не может.
Я для приличия ещё пару вопросов задал, да и попрощался.
Так и состоялось моё знакомство с представителем тех, кто услышал, что "в ИТ большие деньги платят за просто так", и что "мы из вас с нуля за год сделаем девопса".
А по факту за 1,5 года их научили только модным словам и составлению прекрасного резюме.
С тех пор если в резюме встречается слово "Skillbox", и это всё, что там есть - повод задуматься, а стоит ли вообще таких рассматривать.
Вы сталкивались с проблемой, что рабочий проект клонируется 10 минут?
А когда начинаешь разбираться: почему так? То оказывается, что внутри десятки непережатых картинок для фронта, которые еще и менялись регулярно (а значит, оставили след в истории git навсегда).
Данная проблема влияет не только на локальное использование, ведь мы на самом деле довольно редко делаем git clone с нуля, но и самое главное – на скорость всех наших сборок (если мы не используем `fetch-depth: 1` или аналог, а использовать их надо).
Решение: использовать git-lfs!
Обсудили в видео: https://github.com/git-lfs/git-lfs
- Как работает git-lfs на базовом уровне?
- Как мигрировать на него с базового сетапа?
- Как он устроен внутри? Поднимаем https://github.com/git-lfs/lfs-test-server и детально смотрим, что там внутри происходит
Ну и конечно чуть-чуть глянули исходники, они, кстати, на #go 🌚️️️️
Обсуждение: как вы храните большие файлы в рабочих проектах? Насколько большие файлы вы храните?
Команда «Экспресс 42» — консалтинговое направление компании «Флант» — представила пятое ежегодное индустриальное исследование «Состояние DevOps в России 2025». Согласно его результатам, в российском ИТ-сообществе растёт доля высокоэффективных команд, усиливается роль информационной безопасности, а использование ML/AI-инструментов становится нормой для большинства специалистов.
Исследование проведено командой «Экспресс 42» при поддержке Deckhouse, Yandex Cloud, hh.ru, Т-Банка, VK Cloud, AvitoTech, Positive Technologies, ecom.tech, «Онтико», Selectel, X5 Tech, Axiom JDK, Okko и Sk Финтех Хаба и использует результаты опроса более 3300 специалистов из России и стран СНГ.
«DevOps как методология продолжает играть важную роль в реализации технологических проектов, однако эволюционирует вместе с изменяющимся ИТ-ландшафтом — от традиционных практик CI/CD к комплексным внутренним платформам разработки (IDP), DevSecOps и интеграции ML/AI-решений в процессы разработки. Исследование позволяет понять, в каком направлении движется российский DevOps-рынок, где мы сейчас находимся и что необходимо развивать, чтобы команды и бизнес функционировали эффективнее в новых условиях», — отметил Александр Титов, генеральный директор компании «Флант» и сооснователь «Экспресс 42».
Аналитики отмечают рост эффективности DevOps-команд: доля высокоэффективных (Elite) команд выросла на 4 %, High — на 2 %, при этом доля Medium-команд сократилась на 9 %. Улучшились ключевые метрики: срок поставки в Low-командах сократился до 1–3 месяцев, время восстановления в Medium-командах достигло показателя «Меньше дня», а доля неуспешных изменений в Elite-командах упала до 0–5 %.
Команды с высоким уровнем Developer Experience (DX) — то есть с понятной и удобной средой для инженеров — чаще выстраивают быстрые и качественные циклы обратной связи, снижают когнитивную нагрузку и обладают большей автономностью. Среди ключевых факторов высокого DX респонденты отметили развитую инженерную культуру, наличие инструментальной платформы, прозрачные процессы релизов и тесное взаимодействие с безопасностью и эксплуатацией.
«В рамках нашей миссии по распространению передовых практик для достижения технологического суверенитета, мы с удовольствием поддержали открытое исследование рынка DevOps от команды «Экспресс 42». DevOps-решения сегодня — это не просто набор инструментов для автоматизации, а фундаментальный принцип построения высокоэффективных ИТ-команд. Они стирают барьеры между разработкой и эксплуатацией, создавая единый жизненный цикл, в котором скорость не противоречит надежности, превращая ИТ из затратного центра в ключевой драйвер любого бизнеса. Уверен, что исследование поможет многим нашим партнерам внедрить лучшие практики, а разработчикам DevOps, DevSecOps и AIOps-инструментов - лучше понять запросы своих клиентов», - комментирует Павел Новиков, управляющий директор Центра экспертизы Фонда "Сколково"
Информационная безопасность укрепила позиции в процессах разработки. Согласно результатам исследования, 77,1 % участников используют инструменты ИБ, 75,1 % собирают метрики информационной безопасности, а у 66,8 % компаний эти инструменты уже интегрированы в пайплайны. Более того, 40 % респондентов сообщили, что безопасность встроена во все этапы DevOps-цикла — от планирования до эксплуатации.
Наиболее востребованные практики — это интеграция проверок безопасности на ранних стадиях (50 % опрошенных) и параллельная обработка задач в CI/CD (45 %). Чаще всего средства ИБ подключаются именно к системам непрерывной интеграции и доставки — такой вариант отметили 59,9 % респондентов. При этом 46,8 % используют сканеры уязвимостей в образах контейнеров, а 35,6 % — анализаторы конфигураций Kubernetes.
Однако внедрение ИБ сопряжено с вызовами: 45,5 % сталкиваются с нехваткой технической экспертизы, 42,2 % — с проблемами совместимости, а 26,8 % респондентов признают, что результаты проверок им непонятны.
«Как показывает исследование, многие компании всё ещё игнорируют вопросы безопасности разрабатываемого ПО. Знаю, что зачастую активная защита ещё вытесняет превентивные меры типа анализа кода и проведения автоматизированного анализа используемых приложений. Это один из факторов, который “расслабляет” разработчиков ПО. Однако игнорирование подхода безопасной разработки уже становится тупиковой ветвью развития для любого вендора, поскольку одним из наиболее распространённых методов атак на компании до сих пор остаётся эксплуатация уязвимостей веб-приложений (31 %). На фоне постоянно растущего числа кибератак небезопасный код уже нельзя назвать качественной разработкой», — отметила Светлана Газизова, директор по построению процессов DevSecOps и безопасности ИИ, Positive Technologies.
«40 % компаний уже интегрировали безопасность в свой DevOps-цикл. Это очевидный прогресс. Но есть тревожный сигнал: 26,8 % опрошенных говорят, что “результаты проверок им непонятны”. Это значит, что просто добавить сканер в пайплайн недостаточно. Нужно менять подход и культуру работы: делать результаты проверок прозрачными, объяснять их ценность и учить сотрудников правильно их интерпретировать», — подчеркнул Александр Ушаков, DevOps Lead, Okko.
В 2024 году среди опрошенных компаний по-прежнему популярна гибридная модель.
Что касается оценки ключевых преимуществ облачных решений, на первое место выходит повышение надёжности IT-инфраструктуры (82 % в 2024 году против 44 % в 2023 году). Второе и третье места разделяют рост масштабируемости и отказоустойчивости при увеличении трафика текущего продукта (82 %) и соответствие требованиям регулятора в области управления персональными данными (81 %).
Треть компаний используют on-premise-решения по размещению данных в локальной инфраструктуре. Также около трети использовали гибридный формат, храня часть данных в собственной локальной инфраструктуре, а часть — в облаке.
Лидером среди облачных провайдеров стал Yandex Cloud с долей в 47,4 %. На втором месте Selectel — 17,5 %. А третье место делят Cloud.ru и Amazon Web Services, которых выбрали 14,3 и 14,1 % респондентов соответственно.
«Надежность остается одним из главных критериев для бизнеса при выборе инфраструктуры. Компании выбирают облачного провайдера как стратегического партнера, с которым можно уверенно разрабатывать ИТ-продукты, усиливать информационную безопасность и внедрять искусственный интеллект. Несмотря на стремительное развитие продуктового портфеля, мы в первую очередь фокусируемся на обеспечении надёжности, производительности и бесперебойной работы сервисов облачной платформы», – рассказал Иван Пузыревский, технический директор платформы Yandex Cloud.
ИИ-инструменты становятся частью повседневной работы инженеров: 71,3 % опрошенных уже используют ML/AI-решения. Более половины из них (54,1 %) отмечает рост индивидуальной эффективности, 45,6 % — командной. Чаще всего ИИ применяют для автоматической генерации кода (65,2 %), создания документации (45,5 %) и анализа кода на наличие ошибок (45,2 %). Также значительная доля респондентов использует ИИ для автоматического создания тестовых сценариев (34,3 %).
«65 % респондентов уже активно используют автоматическую генерацию кода, а 45 % отмечают значительное упрощение работы с документацией благодаря AI. Эти инструменты постепенно становятся нормой, напрямую повышая индивидуальную и командную производительность. Умение эффективно использовать эти технологии уже сейчас является решающим конкурентным преимуществом, которое будет определять успех бизнеса на ближайшие годы», — рассказал Евгений Харченко, начальник отдела развития практик в разработке и эксплуатации, Райффайзенбанк.
Развитие внутренних платформ (Internal Developer Platform, IDP) остаётся одним из ключевых направлений для компаний. Наиболее важными функциями IDP респонденты назвали управление доступом пользователей (45,8 %) и возможность быстрого поиска информации (45,2 %), а основной целью развития платформ на 2025 год — автоматизацию рутинных задач.
«Internal Developer Platform (IDP) постепенно перестаёт быть нишевым инструментом и становится must-have для крупных компаний с высокой интенсивностью разработки. Сейчас мы видим, что основной спрос на IDP формируют крупные компании с большим объёмом разработки, для которых критически важны унификация процессов, контроль доступа и безопасность», — отметил Станислав Старков, руководитель направления технологической стратегии VK Cloud, VK Tech.
Продолжается переход на российское программное обеспечение и on-premise-решения. Увеличилась доля пользователей отечественных ОС, в том числе Astra Linux, РЕД ОС и «Альт», растёт использование российских дистрибутивов Kubernetes. Каждый четвёртый участник опроса использует российскую ОС как базовый образ для контейнеров, а половина компаний развёртывает оркестратор on-premise.
«Мы на своей практике видим, что востребованность запуска Kubernetes в on-premise стабильно растёт, в том числе за счёт строгих требований службы информационной безопасности и необходимости выполнения требований регуляторов. При этом стоит обратить внимание на достаточно большой процент hybrid-инсталляций, которые позволяют совместить все преимущества собственной инфраструктуры и облачного подхода. Количество запросов на подобный тип инсталляций встречается всё чаще в компаниях разных масштабов, что предъявляет в свою очередь определённые требования к Kubernetes-дистрибутиву. Необходимо, чтобы он единообразно и одинаково хорошо развёртывался и управлял инфраструктурой и в on-premise, и в облаке. Это одна из функциональных возможностей, которая если уже не является определяющей, то должна стать такой в ближайшем будущем», — рассказал Константин Аксёнов, директор департамента разработки Deckhouse, «Флант».
Аналитики отмечают, что наблюдаются устойчивое сокращение доли ручного управления инфраструктурой и рост автоматизации. Увеличивается использование CI/CD- и Observability-систем, растёт доля on-premise-инсталляций GitLab и Kubernetes. При этом заметен тренд на стандартизацию подходов к инфраструктуре и развитие внутренних инструментальных платформ.
Рынок труда DevOps-специалистов в России за последние три года демонстрирует высокую активность: количество вакансий на hh.ru стабильно увеличивалось в среднем на 10 % ежегодно. В 2024 году число опубликованных предложений выросло на 16 % по сравнению с 2023-м, однако в первом полугодии 2025-го зафиксировано снижение — на 26 % относительно прошлого года.
При этом предложение со стороны специалистов продолжает расти: за 2022–2024 годы на hh.ru размещено на 72 % больше резюме, чем в предыдущем трёхлетнем периоде. Количество вакансий, опубликованных суммарно за первое полугодие, превысило количество резюме всего на 18 %. Это минимальный разрыв за последние годы, что свидетельствует о снижении дефицита кадров и росте зрелости индустрии.
«Согласно hh.индексу, в сфере ИТ в целом наблюдается высокий уровень конкуренции соискателей. В августе 2024 года индекс составлял 7,7, а к августу 2025 года вырос до 14,9. Это подтверждает тенденцию работодателей тщательно подходить к найму сотрудников и в сегменте DevOps», — отметила Мария Игнатова, директор по исследованиям, hh.ru.
В целом по итогам исследования State of DevOps Russia 2025 можно сделать вывод, что российский рынок DevOps вышел на этап устойчивого развития. Компании усиливают фокус на эффективности, безопасности и автоматизации, активно интегрируют ML/AI-инструменты и развивают внутренние платформы для ускорения релизов и повышения прозрачности процессов. Продолжается переход на отечественные решения: растёт использование российских операционных систем и дистрибутивов Kubernetes, увеличивается доля on-premise-инсталляций и инструментов на базе открытого кода.
«Российский рынок ПО продолжает идти своим, местами парадоксальным путём: с одной стороны — жёсткое внешнее давление, с другой — необратимое взросление ИТ-ландшафта. В XL-сегменте тренд на интеграцию AI в производственные конвейеры только усилился. “Бигтехи” уже отстроили безопасные внутренние платформы, а теперь метят в AIOps и GenAI-копилотов, выжимая из DevOps максимум продуктивности. Средние и мелкие компании, пережившие кадровую турбулентность 2022 года, почти повсеместно выбрали проверенный OSS-стек — GitLab, Ansible, ELK, Kubernetes. Теперь к нему добавляются отечественные надстройки — от SCA-плагинов с ГОСТ-крипто до репозиториев кода вроде GitFlic. В результате рынок движется к гибридной модели — OSS-база плюс локальные специализированные модули, что и станет реалистичным сценарием 2025–2027 годов», — отметил Дмитрий Гаевский, Technical CPO, Т-Банк.
Об исследовании
«Состояние DevOps в России» — ежегодное индустриальное исследование, которое проводит команда «Экспресс 42» в России и странах СНГ. В исследовании отслеживается распределение организаций по профилям эффективности, определяются факторы, влияющие на эффективность, оценивается развитие инженерных практик. Целевая аудитория исследования — специалисты и руководители, которые тесно связаны с разработкой, тестированием и эксплуатацией программного обеспечения. Для поиска респондентов используется метод «снежного кома»: опрос с помощью рассылок по электронной почте, социальных сетей и маркетинговых кампаний. Это позволяет получить достаточно разнотипную исходную выборку.