Как написать статью и не выжить
Показать полностью
1
0 просмотренных постов скрыто
Сага о стоматологии для ЛЛ. Главы 110-137
По традиции, каждые 27 глав я делаю подборку для самых ленивых. И сегодня у нас 5 часть!
Предыдущие 4 смотрим тут
Погнали!
Пломбу надо переделать.
Из-за плохо переваренной пищи начинает пучить, возникают болезни желудка и плохо всасывается витамин В 12
Не может, так как за движение лица отвечает лицевой нерв, а он лежит в толще щеки и никак не связан с зубами. Может быть только онемение нижней губы или подбородка, если зуб мудрости лежал близко к тройничному нерву, который в движении лица не участвует
Нет. Её можно убрать либо пролечив каналы зуба, либо удалив его
Те деньги, которые вы платите, не идут полностью в карман жадных врачей и владельцев клиник. У них очень много расходов.
1) Пациент плохо ухаживает за полостью рта
2) Дерьмово сделали коронки с плохим прилеганием. Там скапливается налет, который нормально не вычищается.
Восьмерка прорезается, но под таким углом, что одним краем торчит наружу, а вторым упирается в корень семерки.
В этой ситуации между боковой поверхностью семерки и жевательной поверхностью восьмерки образуется углубление, где постоянно скапливается зубной налет. Убрать его оттуда почти невозможно. А учитывая, что у нас и так подавляющее большинство людей задние зубы нормально не чистит, это и приводит как раз к возникновению кариеса.
Чтобы правильно пользоваться съёмными зубными протезами, их нужно чистить минимум дважды в день (лучше — после каждого приёма пищи) щёткой с пастой или специальными средствами из аптеки, избегать жёсткой, липкой и вязкой пищи (орехов, ирисок, целых яблок), обращаться с протезами бережно, не ронять и при снятии на ночь хранить во влажной среде. Период привыкания занимает до 40 дней и включает фазы раздражения, частичного и полного торможения — в это время полезно больше разговаривать, полоскать рот и следить за ощущениями. Если протез натирает, шатается или вызывает боль, его нужно снять и записаться к стоматологу (перед визитом надеть за 3 часа), а для профилактики посещать врача каждые полгода — он при необходимости выполнит пришлифовку или перебазировку.
Его запломбировали резорцин-формалиновой пастой. Если уже, то контролируем, если предлагают-отказываемся и идем туда, где работают более современными методами
1-2 дня, НЕ БОЛЬШЕ
Бесплатно по полису ОМС:
Терапия и пародонтология:
Консультация стоматолога-терапевта
Лечение кариеса пломбой (при разрушении зуба менее 50%)
Лечение пульпита и периодонтита
Снятие зубного камня вручную (до 6 зубов за визит)
Лечение гингивита, пародонтита, стоматита
Шинирование зубов при пародонтите
Лечение повышенной чувствительности зубов
Хирургия:
Консультация хирурга
Простое и сложное удаление зубов (по медпоказаниям)
Обезболивание
Иссечение капюшона при перикороните
Лечение альвеолита
Вскрытие абсцесса (флюса)
Удаление костных выступов и доброкачественных новообразований
Лечение заболеваний слюнных желез
Пластика уздечки губы и языка (детям до 15 лет)
Рентген и физиотерапия:
Прицельные рентгеновские снимки
Ортопантомография (детям и льготникам)
Физиотерапевтические процедуры
Ортодонтия:
Исправление прикуса у детей пластинками (без брекетов)
Протезирование:
Только для льготных категорий (инвалиды, ветераны, пенсионеры, доноры, ликвидаторы ЧАЭС и др.)
Либо пролечиваем каналы зуба, либо удаляем зуб
Выполняем рекомендации лечащего врача
Идем в нормальное место, где лечат современными методами закрываем и нормально лечим. В то место обратно не идем, если не хотим остаться без зуба.
Диоксид циркония, но если предстоит делать длинные мосты, то металлокерамика
Потому что если плохая пломба отвалится потом вместе с коронкой и все придется переделывать, а это будет дороже для всех.
Одиночные более гигиеничные, по возможности делаем их.
Либо на цемент, либо на винт. Выбираем по ситуации
Запчасть, которая формирует контур десны будущей коронки после приживления импланта. Вокруг него должно быть достаточное количество прикрепленной десны, он не должен упираться в кость и он должен быть правильно подобран.
Если у коронки будут нависающие края, то туда будет постоянно забиваться налет, который нереально вычищать. От этого будет воспаляться вокруг импланта десна и кость, это приведет к потере импланта.
Он делает проводниковую анестезию, чтобы блокировать нерв, который проводит между голоткой и суставом челюсти, поэтому кажется, что он делает укол в горло.
Его невозможно герметично восстановить. Даже если сделать, то он начнет быстро гнить.
естественный износ материалов (7–15 лет);
использование некачественного цемента;
недостаточная обработка поверхностей перед фиксацией;
нарушение технологии подготовки фиксирующих материалов;
нарушение технологии внесения материалов (в т. ч. образование воздушных пор);
недостаточная обточка канала зуба;
несоответствие размеров штифта каналу;
слишком короткий штифт (менее ½–⅔ длины канала);
сильное разрушение стенок корня, недостаток феррула;
оставление кариеса под штифтовой конструкцией;
воспаление на верхушке корня с рассасыванием тканей;
чрезмерная жевательная нагрузка (в т. ч. при бруксизме);
привычка грызть твёрдые предметы;
гниение зуба под коронкой.
Палка для чистки зубов из ближнего востока. Если очень хочется, то аккуратно. А так вообще не стоит.
Очень годная вещь для очищения налета из труднодоступных мест. Чистим аккуратно вдоль десны
Корень тупо может треснуть и это деньги на ветер
Не лечиться дешманских ГовноДентах, где-то у черта на залупе.
Дорогие подписчики, на сегодня всё! Сохраняем обязательно пост себе, чтобы не потерять! Обязательно подписываемся и ставим лайк!
Если вы тут недавно, то читаем все главы, уверен, много нового для себя узнаете.
Если есть какие-то вопросы, то смело задавайте в комментариях.
Если что-то персональное, то пишите в ЛИЧНО в телеграм https://t.me/vadbel1310kt, отвечу всем! Консультация БЕСПЛАТНАЯ, мне не жалко.
Если с мессенджерами проблемы, пишите на почту vadbel1310kt@yandex.ru . Сюда же кидаем компьютерную томографию(КТ)
Если что-то срочное, то звоните +79057685253 с 8 до 22 по Москве. Также по этому номер вы можете написать мне в WhatsApp или Max. Если не отвечаю, то значит работаю, пишите!
Если вдруг кому удобнее читать всё это в телеграме, то у меня есть паблик https://t.me/vadbel1310public Там дублируются все посты и удобнее навигация по главам.
Также напоминаю, что любой желающий может получить БЕСПЛАТНОЕ описание своего рентгеновского снимка зубов (КТ, ОПТГ или прицельный) с помощью специального ИИ. ИИ подсветит подозрительные зоны и выдаст понятное описание простыми словами. Это не диагноз и не замена врачу, а удобный инструмент, который помогает ничего не пропустить. Подробнее о том, как это работает, какие есть ограничения и как отправить снимок, читайте в Главе 143:
Снимки для описания присылайте на отдельную почту: vadbel1310snimok@yandex.ru
Просьба писать СРАЗУ ПО ДЕЛУ! Не надо прелюдий "а можно вопрос, удобно ли вам?" и т.д. Сразу пишем желательно по форме. Следующий абзац можете прям скопировать и заполнить.
___________________________
Здравствуйте, я с Пикабу, меня зовут:
Регион:
Это очень важно, чтобы смог сразу понять, к кому можно будет вас направить, если что!
Задаём вопрос. Если вопрос связан с заболеванием, то заполняем форму:
Жалобы: что болит, когда появилось, когда началось… и т.д.
История болезни: когда началось, что, где, когда лечили, и т.д. Соблюдаем хронологию. Стараемся рассказывать покороче. Если возможно, то присылаем фотографию на телефон.
Какие сопутствующие патологии: обмен веществ, инфекционные заболевания, какие препараты принимаем.
Кидаем снимки, если есть. Если есть КТ, то пишем "Есть КТ"
Что бы вы хотели получить от консультации: Совет, направление, лечение?
___________________________
Пишите, пожалуйста, текстом и по форме, мне проще читать. Отвечать буду голосовыми, так как строчить ответ десяткам людей в день тяжело. Без обид, я стараюсь помочь всем! Отвечаю, по возможности, быстро, но так как я практикующий врач и прием у меня достаточно интенсивный, то могу реагировать не сразу. Если вдруг не отвечаю, не стесняемся, через день-другой напоминаем.
Если надо будет описать снимок с помощью ИИ, то смотрим сюда:
Никаких ПЛАТНЫХ медицинских услуг в интернете или по телефону не оказываю! Также у меня нет никаких "представителей" и "учеников", консультирую только лично!
И не забываем вступать в Лигу плохих зубов!
Показать полностью
1
Купил игру - а издатель выключил её. Кто должен отвечать? (Мысли в слух)
Представь: ты купил игру, прошел её, оставил в библиотеке, а через несколько лет решил вернуться. Запускаешь - и ничего. Серверы отключены, игра больше не работает.
Это не паранойя. Так произошло с первой The Crew.
Ubisoft заранее объявила, что после 31 марта 2024 года серверы игры будут закрыты, а сама игра станет недоступна на всех платформах. Издатель объяснил решение ограничениями серверной инфраструктуры и лицензирования. Для владельцев результат оказался довольно простым: купленный продукт перестал быть доступен.
В 2026 году спор дошёл до Евросоюза. Инициатива Stop Destroying Videogames собрала 1 294 188 проверенных подписей граждан ЕС. Организаторы требуют, чтобы издатели не могли просто удалять возможность играть в уже проданные игры после прекращения коммерческой поддержки.
Но Еврокомиссия не стала предлагать обязательный закон, который заставлял бы компании сохранять каждую игру в рабочем состоянии. Вместо этого она заявила, что к концу 2026 года будет обсуждать с индустрией и потребителями способы улучшить практику завершения поддержки игр.
И здесь есть интересный пример. В The Crew 2 Ubisoft добавила гибридный режим: игру можно запускать офлайн, но без некоторых сетевых функций - например, мультиплеера, рейтингов и пользовательского контента. То есть сохранить основную часть игры иногда возможно, хотя полностью прежний опыт уже не получится.
У издателей тоже есть аргументы: серверы стоят денег, лицензии заканчиваются, а бесконечно поддерживать старые проекты невозможно. Но у игроков свой аргумент: если игра продавалась как готовый продукт, почему её существование должно полностью зависеть от решения компании?
Я думаю, разумный компромисс - заранее предупреждать о завершении поддержки и по возможности оставлять офлайн-режим или инструменты для сохранения игры.
Как считаешь? Достаточно просто предупредить о закрытии?
Показать полностью
1
Новый Аршавин или временная аномалия? Вся правда о феномене Батракова в Европе
Два гола за 15 минут. Три удара в створ. И статистика, которая заставляет посмотреть на результат совсем под другим углом. Алексей Батраков всё чаще становится героем футбольных обсуждений. Его сравнивают с большими именами, вспоминают Андрея Аршавина и пытаются понять, насколько далеко может зайти этот молодой атакующий полузащитник.
Но есть одна деталь, которая делает историю особенно интересной. В матче против «Штутгарта» Батраков оформил дубль, хотя его индивидуальный показатель ожидаемых голов оказался значительно ниже двух. Более того, «Галатасарай» победил 2:0, несмотря на то что соперник по некоторым моделям xG создал даже больше опасных моментов.
Получается необычная картина: команда выиграла, но по качеству созданных возможностей выглядела не хуже. А один футболист реализовал практически всё, что получил. Так кто перед нами — будущая звезда европейского футбола или игрок, который сейчас переживает невероятно удачный отрезок? Разберёмся по цифрам.
Два гола, которые не укладываются в статистику
3 ноября 2026 года «Галатасарай» встретился со «Штутгартом» в общем этапе Лиги чемпионов. Матч завершился победой турецкого клуба со счётом 2:0, а главным героем стал Алексей Батраков. Первый гол он забил на 12-й минуте, второй — уже на 15-й. За 77 минут на поле Батраков нанёс три удара, и все три пришлись в створ ворот. Два из них завершились голами.
Для атакующего полузащитника это выдающаяся реализация. Но самое интересное начинается, когда мы обращаемся к xG — показателю ожидаемых голов. Он оценивает вероятность того, что конкретный удар завершится голом. Модель учитывает положение мяча, дистанцию до ворот, угол, тип удара и другие характеристики эпизода.
По данным разных аналитических платформ, индивидуальный xG Батракова в этой встрече составил:
0,52 — Shotify;
0,36 — Squawka;
около 0,51 — StatMuse.
Разница объясняется тем, что платформы используют разные модели расчёта. Поэтому корректнее говорить не об одной абсолютно точной цифре, а о диапазоне оценок. Но общая картина остаётся неизменной: два забитых мяча при ожидаемом количестве голов примерно от 0,36 до 0,52. Иными словами, Батраков реализовал моменты значительно эффективнее, чем можно было предположить по их статистическому качеству. Это и есть главная особенность его выступления.
Однако есть нюанс: высокая реализация в одном матче ещё не доказывает, что футболист способен постоянно забивать с такой эффективностью. Чтобы говорить о стабильном мастерстве, необходимо изучать серию матчей, а не один вечер.
Самая интересная деталь: «Галатасарай» выиграл, но не превзошёл соперника по xG
Вот здесь история становится ещё интереснее. На табло — 2:0 в пользу «Галатасарая». Но статистика ожидаемых голов показывает совсем не одностороннее противостояние.
По данным Shotify, командный xG составил:
«Галатасарай» — 1,01;
«Штутгарт» — 1,77.
FotMob оценивает показатели ещё контрастнее: 0,98 против 2,20. При этом команды нанесли по 13 ударов. По ударам в створ преимущество тоже было у немецкого клуба: 5 против 4.
Что это означает? «Штутгарт» создавал достаточно опасные моменты, чтобы рассчитывать на голы. Но реализовать их не смог. «Галатасарай» же забил дважды уже в начале встречи, и именно эти эпизоды определили итоговый результат. Получается интересный контраст: одна команда создавала больше ожидаемой опасности, другая оказалась гораздо эффективнее в завершении.
Именно поэтому счёт 2:0 не стоит автоматически воспринимать как доказательство полного игрового превосходства «Галатасарая». А выступление Батракова — отдельная история внутри этого матча. Он оказался тем футболистом, который превратил два удачных эпизода в решающее преимущество.
xG — не приговор. Почему статистика не может объяснить всё
Когда футболист забивает два мяча при xG около 0,5, легко сделать поспешный вывод: ему просто повезло. Но это слишком поверхностный взгляд. xG не предсказывает будущее и не определяет, сколько голов футболист обязан забить. Он оценивает вероятность реализации каждого отдельного момента.
Если удар имеет вероятность гола 20%, это не означает, что футболист должен забивать один раз из пяти попыток в строго определённой последовательности. Он может реализовать такой момент с первой попытки, а может не забить десять раз подряд. Именно поэтому один матч не позволяет определить, насколько реализация игрока устойчива.
Есть и другая сторона вопроса. Хороший футболист способен регулярно создавать себе более сложные, но всё же качественные возможности благодаря движению, выбору позиции и своевременному открыванию. Поэтому при оценке атакующего игрока важно смотреть не только на голы и xG, но и на целый набор показателей:
xG — качество моментов, которые футболист завершает ударами;
xA — ожидаемая результативность его передач;
Ключевые передачи — насколько часто он создаёт непосредственную угрозу воротам;
Касания в штрафной — как часто он оказывается в наиболее опасной зоне;
Продвижение мяча — насколько активно он помогает команде переходить от обороны к атаке.
Если голы подкрепляются стабильным созданием моментов, это уже гораздо более убедительный аргумент в пользу высокого класса игрока. А если результативность заметно опережает качество моментов, за такой динамикой стоит наблюдать особенно внимательно.
Почему Батракова сравнивают с Аршавиным
В российском футболе не так много игроков, с которыми можно проводить параллели с Андреем Аршавиным времён лондонского «Арсенала». Но в случае Батракова это сравнение возникает не на пустом месте. В сезоне 2008/09 Аршавин провёл 12 матчей в английской Премьер-лиге, забил 6 голов и отдал 8 результативных передач по статистике официального сайта АПЛ. А затем случился тот самый вечер на «Энфилде».
21 апреля 2009 года «Арсенал» сыграл с «Ливерпулем» вничью 4:4. Все четыре гола лондонского клуба забил Аршавин. Это выступление до сих пор остаётся одним из самых запоминающихся индивидуальных перформансов российского футболиста в английском чемпионате.
Что общего у Аршавина и Батракова? Прежде всего — атакующая смелость и способность принимать решения в ограниченном пространстве. Аршавин не был футболистом, которому обязательно требовалось много времени для подготовки атаки. Он мог получить мяч между линиями, мгновенно оценить ситуацию и одним движением изменить направление всей комбинации.
Батраков интересен похожими качествами: он способен действовать в роли атакующего полузащитника, находить свободные зоны и участвовать в создании опасности, а не просто ждать передачи для завершающего удара. Но здесь важно не торопиться с громкими сравнениями. Аршавин уже доказал свой уровень на дистанции нескольких сезонов в английской Премьер-лиге. Батракову ещё предстоит пройти этот путь. Сравнивать их нынешние достижения напрямую было бы неправильно. Гораздо интереснее наблюдать за сходством игровых качеств и тем, как молодой футболист будет развиваться под давлением европейского футбола.
Что на самом деле показывает тепловая карта Батракова
Теперь перейдём к самому интересному инструменту визуальной аналитики. Тепловая карта — это не просто красивая картинка футбольного поля с красными пятнами. Она показывает, в каких зонах игрок чаще всего взаимодействует с мячом. Чем интенсивнее окрашена определённая область, тем больше действий футболиста приходится на эту зону.
Для атакующего полузащитника это особенно полезно: по карте можно оценить, где именно он участвует в игре — в центре поля, между линиями, на флангах или непосредственно перед штрафной соперника.
В случае Батракова особенно важно сопоставлять карту с другими показателями: передачами, созданными моментами, xA и касаниями в штрафной. Одна тепловая карта не отвечает на вопрос, насколько футболист хорош. Но вместе с остальной статистикой она позволяет понять, какую работу он выполняет на поле и где именно приносит команде пользу.
Голы — это ещё не вся игра: что говорят остальные показатели
Если ограничиться дублем против «Штутгарта», можно решить, что Батраков в первую очередь опасен как завершитель атак. Но статистика матча показывает, что его вклад не сводился к двум ударам.
По данным ScoreInPlay, за встречу он выполнил 34 передачи, из которых 28 оказались точными. Точность составила около 82%. Также в его статистике зафиксированы:
1 ключевая передача;
1 успешная обводка из 1 попытки;
6 выигранных единоборств из 10;
1 отбор;
3 перехвата.
Это уже более объёмная картина. Батраков не просто оказался в нужном месте дважды. Он участвовал в командной игре, вступал в единоборства, продвигал мяч и выполнял оборонительную работу. Конечно, по одному матчу нельзя объявлять его универсальным игроком или делать выводы о стабильности этих показателей. Но для атакующего полузащитника подобная статистика выглядит интереснее, чем простая запись «два гола». Она показывает, что его влияние на матч не ограничивалось завершением моментов.
Так кто перед нами — новый Аршавин или временная аномалия?
На сегодняшний день правильнее не выбирать одну из двух крайностей. Называть Батракова новым Аршавиным пока рано. Для этого недостаточно даже нескольких ярких матчей — необходимы сезоны стабильных выступлений на высоком уровне. Но и списывать его результативность на случайность было бы ошибкой.
В матче со «Штутгартом» он продемонстрировал выдающуюся реализацию: два гола при индивидуальном xG, который разные модели оценивают примерно в 0,36–0,52. При этом он был активен не только в завершении, но и в других компонентах игры.
Самое интересное впереди. После таких выступлений соперники начинают готовиться к футболисту иначе. Ему могут перекрывать привычные зоны, плотнее встречать при получении мяча и ограничивать пространство для разворота. Именно в таких условиях проявляется настоящий класс.
Сможет ли Батраков продолжать создавать опасность, когда ему перестанут давать свободное пространство? Сохранится ли высокая результативность? Будет ли он влиять на игру даже тогда, когда не забивает? Ответы на эти вопросы гораздо важнее одного дубля.
Пока же можно сказать одно: Батраков уже заставляет смотреть на свою игру внимательнее. И дело не только в голах. Аршавин когда-то заставил болельщиков запомнить свой номер на «Энфилде». Батраков только начинает собственную историю. И сравнивать их сейчас интереснее не по количеству забитых мячей, а по тому, насколько сильно они способны менять ход матча.
А как считаете вы: у Батракова действительно есть потенциал вырасти в футболиста масштаба Аршавина или мы пока наблюдаем невероятно яркий, но временный отрезок?
Показать полностью
5
Заметки для ИИ вкатунов. Нейрослоп, сообщества, геймдев по-русски
Возможно, будет немного сумбурный пост)
С недавнего времени начал вариться в геймдеве, анализировал сообщества, больные темы и что вообще получается ? Пробежимся по темам:
1. Вайбкодинг и вкатуны.
Думаю, каждый из вас обратил на это внимание. Есть разные позиции на эту тему:
вайбкодинг - это "без души"
старая школа вайбкодинг не признаёт ни в каком виде
разработчики, которые используют, но в помощь
Обратите внимание, эти темы прям проскальзывают всё чаще. А оно и понятно - те люди, которые до нейронок проходили весь этот тернистый путь разработки, находились (или находятся по сей день) в производственном аду - не то что завидуют, их это раздражает (0 осуждения, 100 понимания).
Представьте - человек или команда вкладывали душу не один месяц или даже годы, а тут набежала толпа вкатунов и такая - смотри, что сделал!
Резонный вопрос появляется - чего ты там сам-то сделал? Ну автор идеи, и то, идея скопирована. Но эти вопросы не задаются, они витают, люди просто не хотят устраивать холивар, потому что он бесполезен.
Немало людей, которые допускают в своих проектах нейронку, но только исключительно в рутинных процессах и при отсутствии команды. И эта часть людей спокойно принимает тот факт, что бороться с ИИ не нужно, им просто надо уметь пользоваться, это будущее, как ни крути. Конечно, пользоваться ИИ или не пользоваться им - исключительно позиция каждого.
Просто уважайте разработчиков, которые долго и кропотливо занимаются своим проектом.
2. Чистый нейрослоп…
Это прям очень актуальная тема. Тут существует даже такая проблема, что нейронки очень хороши в генерации картинок, и в интернете начинают называть нейрослопом то, что было сделано вручную - представьте, им надо доказать, что они не верблюды...
Наверное, основной посыл этой темы в том, что появляется настолько непроработанный нейрослоп, что аж становится противно. Это вот насколько автор не озадачился хотя бы подкруткой генерации. Вот настолько - ему было наплевать... (подробнее в другом пункте).
Подобные игровые проекты просто засоряют сообщество, что начинает убивать индустрию инди в целом. Собрать игру на коленке за 2 дня и показать, мол - смотрите, убийца Майнкрафта! - дядя, не надо, пожалуйста.
Если вас одурманило чувство, что вы теперь "разработчик", и игру за 2 дня хотите показать интернету - поверьте, не стоит, в интернете это знают, в интернете есть люди, которые так умеют, не засоряйте эфир.
Таким "мусором" вы убиваете настоящих разработчиков с реально достойными проектами. Вы всего 2 дня и то с подпиской в 20$, вы даже не представляете, какой огромный труд стоит за продвижением проекта. А вы своими проектами просто "растворяете" площадки, где теряются проекты, достойные внимания!
Если вы не стараетесь - просто не выкладывайте. Покажите друзьям, родителям, этого вам хватит для поддержки и своей важности.
3. У меня крутая идея для игры!
Скорее всего, нет - просто вам так кажется. И "идея" не равно "реализация". Вы можете придумать сотни механик, реально интересный сюжет, аспекты, которые проработали - но это у вас всё в голове, детализировано за каждый момент вы и не думали. И вы встретитесь с этим, когда даже через вайбкодинг начнёте собирать всё по кирпичикам, и наступит тот момент, когда придёт осознание, что вы возводите кирпичную стену без фундамента, да и по факту вместо коттеджа получился курятник. Был пост про диздок, ознакомьтесь с ним (как минимум).
А главное, задайте себе вопросы - что это за игра и для кого она? Чем увлечёте игрока больше чем на 10 минут?
Представьте, завтра приходит инвестор и задаёт эти вопросы - от качественного ответа зависит, впишется за вас издатель или нет)
4. Мой текст - не мой текст.
Всё чаще я начинаю замечать, что авторы совсем обленились. Ну то есть, несмотря на то, что игра просто ужасный нейрослоп, так ещё автор и не потрудился сам презентовать свой прототип. Это уже не то что непрофессионально, это очень глупо. Люди, работающие с нейронкой, видят это сразу, и для кого тогда это написано? Если вы не в состоянии описать своими словами, что за игра, о чём она - для чего вы вообще пишете тогда посты? Вы ждёте оваций? Вы только вдумайтесь, что вы пишете в лигу разработчиков нейронный текст... Это как прийти с оружием в полицию, только в данном случае вы ещё и стреляете себе в ногу...
5. Нейронка всё не сделает!
Не питайте надежды, что за вас всё сделает нейронка (конечно, если ваша игра не из двух кнопок). Если вы не притрагиваетесь к проекту совсем - это будет нейрослопом, который раскусывают сразу, и шансов вообще кого-то заинтересовать нету (и выкладывать такое не нужно).
Игры по-прежнему требуют ручной работы, именно руками игра приобретает свой стиль и качество, и чем более трудолюбиво вы участвуете вручную, тем меньше будет хейта, что это халтура.
6. Я хочу зарабатывать на играх!
Забудьте. Таких, как вы - тысячи, а возможно, сотни тысяч. Все ищут возможность заработать быстро и легко, не думайте, что эта формула отработается на вас от первой подписки GPT или Claude. Если вы увидели пару постов, где одиночка-разработчик разбогател, и вас это мотивирует - вы не реалист, к сожалению. Дело в том, что разработчиков много, инди-жанр переполнен уже настолько, что, как я и говорил - теряются реально уникальные и крутые игры, на 10 голов выше, чем то, что вы собираете через нейронки.
Хотите демо-версию заработка? Пф, попробуйте склепать пару игр для Яндекса и ВК. Вы не помешаете реальным разработчикам (там в основном студии) и посмотрите, что такое конкуренция, что такое доход, и если ваша игра не увлекательная - возможно, в голове щёлкнет мысль - делать упор на качество, а не проходняк. Вот на моменте пары отказов в модерации и проверите себя, насколько вы готовы заходить в эту сферу и делать всё до конца...
Ну на сотню нейрослопа в целом - заработать можно, наверное. Пробуйте сами
Также я начал встречать любимую мною тему - "бесплатная игра, но мне нужны деньги". Открою секрет - деньги всем нужны, только не рассказывайте никому.
Если вы прикрываетесь условно-бесплатным проектом, но из вас так и прёт расположить везде кнопки на донат, попросить денег на стадии прототипа и заработать первую копейку - завязывайте с этим навсегда.
Разработка игр - это изначально убытки в виде денег и времени. Это та индустрия, где нужен авторитет, и как только вы его получите, тогда, возможно, упадёт первая монета. Без усердных и длительных вложений это просто выглядит как попрошайничество, при этом с жёсткой халтурой в виде проекта.
7. Реклама и сообщества
Допустим, вы сделали что-то ближе к достойному. Что делать? А вооот теперь самый сложный этап, который ещё и не все проходят.
Представьте, вам идея и реализация кажутся вполне достойными, но игроков нет. Вы начинаете презентовать свою игру - но не набирается даже минимальное количество интересующихся. Вишлисты (если вы всё-таки решились релизнуться в Стим за 100 баксов) не дают гарантии, что именно столько людей и сыграет...
Да, на этапе разработки следили 5 человек, ну готовы они сыграть, сыграли... Что по успеху? Его нет) Поздравляем, вы в геймдеве!
Представляете - такое бывает и достаточно часто, я писал выше про такие проблемы, и вот они касаются вас. Что делать? Ну конечно, вы оцениваете рынок, и знаете, что видите? О да, любимый нейрослоп) , вы дропнули свою игру сегодня утром в демо-режиме, к обеду вы видите, как игра в конце списка, а к вечеру и вовсе на третей странице. Ну вот, круг замыкается! И скорее всего - вы не особенный со своим проектом, вы как все))
Ну дальше, конечно, побежим в сообщества инди-разработчиков в попытке привлечь игроков (до инвесторов-то далековато, ваша игра на нейронке, ну камон, думаете, вам лям отстегнут?). Находите все сообщества (а большинство раскручено ботами), дропаете презентацию игры, что получаем? Палец вверх или какашки, комменты - возможно по существу, пару подписок, ну допустим сотня и всё.
В чём беда? Нету нормальной рекламы для игроков (это не проблема пабликов). То есть когда вы заходите в сообщества и вы рекламируете своё "блюдо" таким же поварам, как и вы - насколько это честно? Поддержка и критика - возможно, но вы искали игроков, а получается, что вы в сообществе разработчиков, таких же как и вы, а там каждый болеет за свой продукт - но насколько это "реклама"?
Ну тут крутитесь как можете, если вас терпение не подведёт)
Вот и подходим к насущному итоговому вопросу - насколько вы готовы всерьёз пройти все эти этапы? Потратить уйму времени, денег, нервов - ради чего? Если вы не энтузиаст, который оценивает реально убыточные риски и готов корпеть над своим проектом - тогда поумерьте свои амбиции, а лучше попробуйте себя в гонке среди таких же в Яндекс Играх и ВК, считаю, там вы наберетесь и опыта и оцените старания других.
Уважайте труд других и поддерживаете друг-друга. Если берётесь - то делайте качественно
Показать полностью
2
Гибридный хостинг против чистого облака:считаем деньги на реальном примере
Спор облако или своё железо» никогда не заканчивается. Потому что обе стороны считают правильно, но берут в расчёт разное. Поэтому цифры у всех верны, а сравнивают они не одно и то же. Провайдер облака показывает цену за час, а поставщик железа называет цену за месяц. Но реальная стоимость владения – это не только цена железа или облака. Она складывается из нескольких вещей. Нагрузка, которая меняется в течение суток. Простой тоже стоит денег. Ещё нужно учитывать зарплаты инженеров, и расходы на электричества. В итоге решение принимают, просто сравнивая два варианта напрямую. Однако аналитики отмечают, что такое сравнение почти всегда некорректно. Оно ставит рядом покупку своей инфраструктуры и использование сервиса. А это принципиально разные модели. У них различаются затраты и ответственность.
В статье разберём конкретный сценарий. Это веб-сервис с предсказуемым дневным пиком и ночным спадом. Сравним два варианта. Первый сценарий означает только облако. Второй это гибридная схема, где базой служит арендованный физический сервер, а на время пиков добавляются облачные ресурсы. Цифры берём из актуальных российских прайсов 2026 года. Цель не доказать, что один подход всегда лучше, а показать, при каких условиях выигрывает каждая модель.
Сценарий: нагрузка, которую можно посчитать
Представим API-сервис с базой данных PostgreSQL. Средняя нагрузка — около 500 тысяч запросов в сутки, но распределены они неравномерно: 70% приходится на московский день, с 9 до 21 часа, а ночью трафик падает до 15–20% от дневного уровня. Пиковое потребление — примерно 8 vCPU и 32 ГБ RAM. Ночью достаточно 2 vCPU и 8 ГБ. Данные занимают 200 ГБ на SSD.
Такая нагрузка является типичным кандидатом для гибридной схемы, потому что пик предсказуем. Если бы нагрузка была равномерной, гибридная схема потеряла бы смысл. Физический сервер простаивал бы ночью, а облако не давало бы экономии за счёт масштаба.
Вариант первый: чистое облако
Виртуальная машина с 16 vCPU и 64 ГБ RAM обходится примерно в 32 рубля в час с НДС. Для пикового периода в 12 часов это около 384 рублей в сутки. Ночью можно переключиться на конфигурацию с 12 vCPU и 24 ГБ RAM — примерно 24 рубля в час, или 288 рублей за оставшиеся 12 часов.
За сутки только вычислительные ресурсы стоят около 672 рублей. В месяц это примерно 20 тысяч 160 рублей. К этому добавляются диск на 200 ГБ, публичный IP, трафик и резервные копии. Реалистичная итоговая сумма для такого сценария в облаке составляет от 25 до 30 тысяч рублей в месяц.
Это только прямые затраты на ресурсы. Облако делает мощности гибкими и избавляет команду от работы с железом. Однако без инженера не обойтись. Он настраивает автоскейлинг, следит за метриками и разбирает инциденты. Для сервиса такого масштаба речь идёт не о полной ставке сисадмина, а о доле его времени. Но эти издержки всё равно есть.
Вариант второй: гибрид — физический сервер плюс облако на пиках
Аренда физического сервера снимает проблему ночного простоя, потому что вы платите фиксированную сумму независимо от нагрузки. По прайсам российских провайдеров сервер с двумя Xeon E5-2667v4 (16 ядер, 32 потока), 128 ГБ RAM и SSD на 500 ГБ обходится примерно в 15 тысяч рублей в месяц. Этого с запасом хватает для пиковой нагрузки 8 vCPU / 32 ГБ. Ночью сервер работает вполсилы, вы платите за него, но не переплачиваете за облачные часы.
Однако гибрид не означает «только физический сервер». Если нагрузка превысит возможности железа, например, из-за внезапного скачка трафика или сезонного всплеска, подключается облако. Добавляем облачный резерв на 20–30% времени, когда выделенного сервера не хватает. По тем же облачным тарифам это добавляет примерно 6 – 8 тысяч рублей в месяц.
Итого гибрид: около 15 тысяч (железо) + 7 тысяч (облачный резерв) = 22 тысячи рублей в месяц. Плюс электричество, если сервер не арендован с включённым питанием, а размещён в дата-центре. В первом квартале 2026 года средняя цена колокации стандартной стойки в Москве составила 162 тысячи рублей. Но для одного сервера это подходит, потому что аренда выделенного сервера уже включает питание и место.
Что не попало в расчёт: скрытые затраты
Прямое сравнение 22 тысяч против 27 тысяч выглядит в пользу гибрида. Но разница всего 5 тысяч рублей в месяц. Это не вывод, а начало разговора. Аналитики указывают на несколько статей, которые почти всегда упускают.
Первая — стоимость простоя. Физический сервер — это единая точка отказа. Если он откажет, сервис будет полностью недоступен, пока его не переключат на резерв. В облаке сбой одной виртуальной машины не останавливает сервис, потому что замену можно запустить за минуты. Если час простоя стоит для бизнеса, скажем, 50 тысяч рублей, то один незапланированный инцидент в год съедает всю экономию гибрида.
Вторая — зарплата инженера. Гибрид не работает сам по себе. Нужен человек, который следит за железом, обновляет прошивки, меняет диски и разбирается с сетевыми проблемами на физическом уровне. Средняя годовая зарплата системного администратора в России в 2026 году — около 1,84 млн рублей, или примерно 153 тысячи в месяц. Если специалист тратит на гибридную инфраструктуру 10% своего времени, стоимость такой схемы вырастает на 15 тысяч рублей в месяц. Тогда разница с облаком либо исчезает, либо становится противоположной.
Третий пункт — это электричество, если речь идёт о собственном железе, размещённом в дата-центре. Ценовой индикатор на электроэнергию для промышленных потребителей в апреле 2026 года составил 6,66 рубля за кВт·ч с НДС. Сервер с потреблением 300 Вт в месяц съедает около 216 кВт·ч, то есть примерно 1 440 рублей. Это немного, но в колокации к этому добавляются стоимость места, охлаждение и услуги удалённой поддержки.
Когда каждая модель выигрывает
Гибридная схема выигрывает, когда нагрузка предсказуемая, но неравномерная. Пик можно закрыть своим железом, а облако использовать только как страховку. Если у команды уже есть инженер, знакомый с физическими серверами, и бизнес готов принять риск единой точки отказа ради экономии, гибрид даёт ощутимую разницу в бюджете.
Чистое облако выигрывает в трёх случаях. Нагрузка непредсказуема. Команда небольшая и не хочет заниматься железом. Простой обходится дорого. В этих случаях доплата от 5–10 тысяч рублей в месяц не является переплатой. Это плата за эластичность и распределение рисков. Облако оказывается предпочтительнее и у быстрорастущих проектов. Не нужно закупать инфраструктуру на 2–3 года вперёд и мириться с тем, что купленное простаивает.
Есть и третий вариант, который часто остаётся в тени. Речь идёт об облаке с резервированием ресурсов. Некоторые провайдеры дают скидку до 15% на долгосрочную аренду выделенных серверов при оплате за год. Такой подход не гибрид, однако он позволяет снизить стоимость чистого облака, если нагрузка стабильна.
Практические выводы
Смотрите не цену ресурса, а на полную стоимость модели. Если учесть долю зарплаты инженера, а также стоимость риска простоя, разница между 15 тысячами за железо и 25 тысячами за облако исчезает.
Гибрид оправдан только при предсказуемой нагрузке. Если пики случайны, физический сервер будет простаивать, а облачный резерв придётся использовать чаще, чем вы рассчитывали.
Не стоит сравнивать железо с лицензиями и подписку. Сравнивайте два полных сценария, где учтены инженер, риск простоя и гибкость. Прямое сравнение почти всегда искажает картину.
Сервисам с высокой ценой простоя облако часто обходится дешевле, даже если на бумаге оно дороже. Один инцидент может перечеркнуть годовую экономию.
Для стабильных нагрузок и команд с опытом физического администрирования гибрид остаётся рабочим вариантом. Но только если честно посчитать, сколько времени и сил он на самом деле съедает.
Гибридный хостинг и чистое облако не конкурируют между собой. Это инструменты под разные нагрузки и команды. В нашем сценарии гибрид экономит около 5 тысяч рублей в месяц на прямых затратах. Но эта экономия быстро тает, как только вы добавляете стоимость человеческого времени и риск единой точки отказа. Хотя чистое облако на бумаге стоит дороже, вы платите за гибкость и распределение рисков. Для многих бизнесов — это оправданные расходы. Правильный ответ зависит не от прайса провайдера, а от того, насколько предсказуема ваша нагрузка, как велика цена простоя и сколько времени ваша команда готова тратить на железо вместо продукта.
Показать полностью
2
Внутренняя платформа разработки: можно без Enterprise, но работать всё равно придётся
Внутренняя платформа разработки: можно без Enterprise, но работать всё равно придётся
Я много лет занимался инфраструктурой. Потом ушёл в продукт, а привычка смотреть, как у людей устроена разработка, осталась. Особенно интересно становится на вопросе: «Что нужно сделать, чтобы задеплоить новый сервис?»
Иногда в ответ дают ссылку. Иногда начинают перечислять, кому надо написать. Вот об этом и поговорим.
По данным исследования State of DevOps Russia 2025 (более 3300 респондентов), половина участников уже работает с одной или несколькими внутренними платформами разработки (47%), а около трети внедрять их не планирует (37%). Половина компаний тратит на внедрение IDP от 10 до 30% своих ресурсов. В пользу сборки на open source это выглядит убедительно, хотя из цифр о ресурсах состав стека не узнаешь.
Я понимаю желание купить готовое. Но сначала хочется выяснить, за что именно платим и кто потом будет это обслуживать?
Сначала разработчику нужен доступ
Типичная картина. Новый человек пришёл в команду, получил продуктовую задачу и пошёл настраивать окружение. Dev отличается от stage, prod отличается от обоих. Потому что настраивали разные люди и в разное время.
Чтобы выкатить фичу, нужно написать «дай доступ». Подождать. Потом повторить для трёх разных систем. Документация есть, но часть в репозиториях, часть где-то ещё, а последнее изменение помнит только тот, кто его делал.
Он сейчас занят.
Пока команда маленькая можно договориться в чате, но с ростом команды те же простые операции начинают съедать время DevOps и платформенных инженеров, потому что каждому разработчику приходится ждать человека, который может их выполнить.
IDP - Internal Developer Platform, внутренняя платформа разработки - выносит такие действия в самообслуживание. Разработчик заходит в одно место, сам поднимает окружение или деплоит сервис. Там же находит документацию, смотрит метрики. У платформенной команды остаётся время на саму платформу.
Звучит скучновато. Зато можно работать.
А можно купить коробку?
Можно. Есть коммерческие платформы для developer portal, CI/CD, управления инфраструктурой, governance и self-service. В большой организации готовые интеграции и поддержка могут окупиться. Особенно когда нужны аудит и строгая ролевая модель, а за требования безопасности кто-то отвечает подписью.
Но представим команду в 30 человек. Ей тоже продают весь этот набор. Красивый интерфейс, впечатляющий список возможностей. Какие из них понадобятся в работе?
Тут я обычно и начинаю задавать неудобные вопросы.
Многое можно собрать из открытых компонентов. За проектами стоят CNCF, Spotify, HashiCorp и другие организации, тысячи контрибьюторов. Только лицензию конкретного продукта всё равно читаем (после истории с HashiCorp особенно).
И честно считаем работу. Внедрение тоже стоит денег. Интеграции тоже. Обновлять и чинить будет своя команда. Если убрать лицензионный платёж из сметы, инженеры бесплатно работать не начнут.
Мне интересна полная стоимость, включая эксплуатацию. С ней уже можно сравнивать предложение вендора.
Что придётся собрать
Слои у платформы разные. Все сразу устанавливать я бы не торопился, сначала нужно понять, где у команды очередь.
Портал. Где найти документацию по сервису? В Confluence, README, у Димы. Backstage собирает каталог сервисов с владельцами, документацию и шаблоны новых компонентов в одном интерфейсе. Это open source-проект Spotify под управлением CNCF.
Backstage на слуху, но установить его и получить работающую IDP - разные задачи. Это фреймворк. Каталог нужно наполнить, шаблоны написать, интеграции подключить под свои процессы.
После установки работы ещё достаточно.
Ресурсы по запросу. Разработчику нужна база. Он пишет DevOps, ждёт. Потом выясняется, ещё очередь и S3-бакет. Ещё сообщение, ещё ожидание.
Terraform или OpenTofu описывают ресурсы кодом. OpenTofu появился как открытый форк после смены лицензии HashiCorp. Когда команда подготовила модули, записала правила и настроила права вместе со способом запуска, разработчик может заказать нужное сам, причём контроль у инфраструктурной команды остаётся. Ресурсы создаются по тем правилам, которые она определила.
Сам по себе файл с описанием инфраструктуры такого сервиса не создаёт. Его ещё надо встроить в процесс.
Доставка кода. GitLab CI, GitHub Actions, Argo CD. Пайплайн рядом с кодом, деплой запускается пушем или кнопкой, без звонка в соседний отдел.
По данным State of DevOps Russia 2025, доля респондентов, использующих Argo CD, за год выросла с 14 до 21,8%, Flux CD - с 2,8 до 6,2%. GitOps растёт, хотя пока остаётся выбором меньшинства. Суть подхода: желаемое состояние хранится в Git, инструменты приводят фактическое к нему. Только CI и GitOps-контроллер делают разную работу, это нужно учитывать при сборке.
Окружения. Kubernetes как основа, Helm для упаковки приложений. Через Crossplane можно управлять внешними облачными ресурсами с помощью Kubernetes API. Удобно, если команда уже работает декларативно и хочет так же описывать инфраструктуру.
Но жизненный цикл базы от этого не становится таким же, как у приложения. За одинаковыми манифестами всё равно стоят разные ресурсы.
Что там сломалось? Prometheus + Grafana для метрик, Loki для логов. Разработчик сам смотрит, жив ли сервис, сколько ошибок и что было перед инцидентом. В три часа ночи очень хочется иметь такую возможность. Без отдельного квеста «найди DevOps».
Теперь глазами нового человека
Вместо инструкции на 40 страниц ему дают ссылку на портал. В каталоге шаблоны: Python API, Go-сервис, фронтенд на React. Выбрал нужный - пошла подготовленная цепочка.
Создался репозиторий со структурой проекта. Подключился CI/CD, поднялось dev-окружение и нужные инфраструктурные ресурсы. Сервис появился в каталоге, мониторинг тоже настроен.
Красиво? Да. Если команда заранее подготовила golden path и всё это связала между собой.
Через несколько минут разработчик получает рабочую заготовку по стандартам компании. Для своего внедрения я бы замерял время отдельно. Где человек начал работу, на чём остановился, сколько пришлось делать руками.
Спойлер: поставленный Backstage не мешает людям по-прежнему просить доступ в чате. Пока этот сценарий не переделан, так и будут просить. Проблема типовая, в State of DevOps Russia 2025 управление доступом названо самой важной функцией внутренней платформы (45,8% респондентов).
Грабли с красивым интерфейсом
Сначала месяцами выбирают плагины, потом спрашивают разработчиков, что им мешает. Оказывается, долго поднимается окружение, документацию не найти, доступы надо выпрашивать. Начать стоило с этого разговора, а портал подождал бы.
Есть и другая история: платформу сделали, пользоваться обязали. Удобно ли? «Мы так решили». Ну да, внутренние пользователи ведь не могут уйти к конкуренту.
Я бы смотрел, сколько людей реально пользуются платформой и сколько занимает создание сервиса. Какие ручные операции остались? Стало ли меньше обращений к платформенной команде? Если нет, выясняем причину, даже когда интерфейс всем нравится.
Следующие грабли- эксплуатация. Backstage обновлять, плагины поддерживать, Kubernetes обслуживать. Где-то ещё сломается пайплайн. На всё это нужен человек с выделенным временем.
Я бы закладывал хотя бы одного, для кого платформа - основная задача. Вариант «кто-нибудь поправит между делом» со временем деградирует. И обычно это замечают в самый неудобный момент.
Ну и автоматизация процесса, который никто толком не описал. Если деплой вручную устроен плохо, сначала разбираемся с порядком действий и ответственностью. Иначе просто запишем ту же путаницу в код. Она станет воспроизводимой, только радости мало.
Где всё-таки нужен Enterprise
Границы «до ста разработчиков хватит open source» я не знаю. Размер команды сам по себе мало что говорит.
Может быть большая команда с довольно простой инфраструктурой. Может быть маленькая, но с жёсткими требованиями безопасности. Во втором случае коммерческое решение иногда обходится дешевле собственной сборки.
Смотрим на количество команд и кластеров, multi-cloud, compliance. Потом на ролевую модель, аудит и круглосуточную поддержку. Есть ли свои люди, которые это потянут? Вот тут расчёт становится интересным.
Перед контрактом я бы попросил назвать конкретное ограничение, что на открытом стеке сделать не получается или слишком дорого поддерживать, сколько времени съедает эта работа и как изменится ситуация после покупки продукта с централизованным аудитом, сложными правами и готовыми интеграциями?
«Нужна поддержка» - тоже нормальный ответ. Только уточните, какая, с каким временем реакции и кто будет работать с обращениями на вашей стороне. А то подписка есть, инцидент есть, ответственный где-то потерялся.
С чего я бы начал
Возьмите создание нового сервиса и пройдите его вместе с разработчиком. От первого запроса до работающего окружения. Запишите, где пришлось ждать чужого действия.
Выберите такую остановку и уберите её через самообслуживание. Потом повторите проход. Если стало быстрее и команда готова это поддерживать, можно двигаться дальше. Заказывать весь каталог инструментов пока рано.
Показать полностью
Почему ваш CI/CD медленный: профилирование пайплайнов и устранение узких мест
Тесты могут выполняться быстро, а проверка коммита всё равно занимать полчаса. Runner ждёт свободного слота, получает исходники, поднимает окружение, распаковывает зависимости. После тестов остаются отчёты и артефакты. Ускорение самой тестовой команды затронет только часть этого времени.
Для разбора нужен профиль всего запуска. Ниже используется GitLab CI с собственными runner и приложение на Node.js. Примеры конфигурации рассчитаны на существующий проект; минуты в схеме и расчёте кэша условные. Реальный выигрыш определяется по его логам.
Сначала собрать временную шкалу
У разработчика и CI разные точки отсчёта. Человек начинает ждать после отправки коммита, исполнитель позже. Конечная точка тоже зависит от задачи: первая ошибка в merge request или законченный релиз. Ручное одобрение выпуска выделяется отдельным интервалом, иначе ожидание согласования легко принять за медленную инфраструктуру.
В Jobs API GitLab есть queued_duration, duration, started_at и finished_at. К выгрузке стоит добавить SHA, тип запуска, runner, имя задания и статус каждой попытки. Ответ приходит постранично, а повторные задания включаются через include_retried=true. Без них успешный повтор будет выглядеть лучше, чем всё ожидание с первой неудачной попыткой.
Для начала достаточно истории сопоставимых запусков. Полный ночной прогон и проверка маленького merge request решают разные задачи. Даже на одной машине их нельзя сравнить как результат одной настройки. Внутри выбранной группы отмечаются холодный кэш, версии образов и повторные попытки.
Далее в trace ищутся границы операций. GitLab Runner получает исходники, восстанавливает кэш и скачивает входящие артефакты до пользовательских команд. После них идут дополнительные шаги, включая after_script и отправку результатов. Поэтому зелёная строка тестового фреймворка вполне может появиться задолго до окончания задания.
Если время пропало до старта, проверяются доступные runner и теги. Свободная машина с неподходящим тегом не разгрузит очередь этого задания. Если задержка внутри загрузки зависимостей, нужны сеть и registry. Если после тестов, следующий объект разбора уже архив или отчёт. Эти различия должны появиться в профиле до выбора исправления.
Измерить команду отдельно от задания
В Linux-образе с GNU time установку можно обернуть следующим образом. Строки добавляются в существующий script:
/usr/bin/time -f 'elapsed=%e user=%U sys=%S maxrss_kb=%M' \
-o npm-ci.time npm ci --cache .npm --prefer-offline
cat npm-ci.time
Показатели определены в описании GNU time: elapsed означает время по часам, user и sys время CPU, %M максимальный RSS в килобайтах. Встроенный time оболочки может не поддерживать этот формат. Максимальный RSS также не является суммарной памятью всех параллельных контейнеров.
При ошибке установки оболочка может остановиться до cat. Файл измерения поэтому забирается через artifacts с when: always. Для сборки и тестов нужны отдельные файлы. Полная трассировка set -x для замера не требуется и может показать секреты из аргументов команд.
Большой elapsed при малом времени CPU указывает на время вне вычислений, но ещё не называет его причину. Команда могла ждать сеть, диск, другой процесс или доступ к CPU при ограничении контейнера. Нужны метрики хоста за тот же интервал и ограничения контейнера. У однопоточной программы иной предел: дополнительные ядра не ускорят участок, который она выполняет последовательно.
Найти цепочку, которая задерживает результат
Длительности четырёх заданий сами по себе не определяют время пайплайна. Пусть build занимает 6 минут, unit-тесты 4, интеграционные 8, lint 1. По очереди получится 19 минут. Если обеим группам тестов нужен только build, а lint независим, при достаточных ресурсах получается 6 + max(4, 8) = 14 минут. Подготовка, очереди, передачи файлов и выпуск здесь не учтены.
Даже сокращение unit-тестов с четырёх минут до двух не изменит эти четырнадцать: позже заканчиваются интеграционные. Минута экономии на build, напротив, сдвигает обе группы. Приоритет определяется критическим путём, то есть цепочкой зависимостей, от которой зависит окончание нужной работы.
В GitLab такие связи задаёт needs. Для существующего build и скрипта интеграционных тестов:
integration:
stage: test
needs:
- job: build
artifacts: true
script:
- ./ci/integration.sh
Интеграционная джоба сможет стартовать после build, не дожидаясь остальных заданий предыдущей стадии. Нужные файлы сам build должен публиковать в artifacts: paths. Перечень needs определяет и источники входящих артефактов, поэтому после изменения графа проверяется происхождение пакета.
Для ветки, merge request и тега графы могут отличаться из-за rules. Если обязательный производитель исключён из графа, необязательная зависимость не создаст отсутствующий пакет. Независимый lint можно запускать раньше ради первого полезного ответа, даже когда срок релиза почти не меняется.
Посчитать полную цену кэша
Пометка cache hit сообщает, что данные нашлись. Она ничего не говорит о затратах на их получение. В условном примере восстановление архива занимает 25 секунд, его упаковка и отправка ещё 20, а установка экономит 30. Джоба в итоге потеряла 15 секунд. Если сравнить только время установщика, результат получится противоположным.
У npm встречается ещё более прямой расход: runner распаковывает node_modules, после чего npm ci удаляет существующий каталог перед установкой. Для такой последовательности стоит проверить сохранение скачанных пакетов .npm. Следующий фрагмент предполагает подходящий Node.js и закоммиченный lock-файл:
cache:
key:
files: [package-lock.json]
paths: [.npm/]
script:
- npm ci --cache .npm --prefer-offline
- npm test
Флаг --prefer-offline оставляет возможность загрузить недостающее из сети, поэтому registry и авторизация остаются нужны. Рассогласование package.json и lock-файла вызовет ошибку при любом состоянии кэша. Сохраняются и настройки npm, с которыми создавался lock-файл.
В сравнении участвуют полные джобы, отдельно с холодным и прогретым кэшем. Если получение архива дороже экономии, меняется его состав или сам механизм. У кэша GitLab нет гарантии доступности: промах должен оставлять рабочую сборку. Обязательный пакет конкретного коммита передаётся артефактом задания, которое его собрало.
В общем кэше также нужны понятные права записи. Недоверенная ветка не должна подменять содержимое для защищённого релиза. При нескольких писателях с одним ключом стоит проверить, чей архив останется последним; заданиям, которые только читают его, подходит policy: pull.
У Docker повторная установка может зависеть от порядка COPY. При раннем COPY . . изменение исходника способно инвалидировать слой зависимостей. Манифест и lock-файл можно скопировать отдельно, вместе с файлами, которые действительно нужны install-скриптам. .dockerignore уменьшает контекст, сохраняя необходимые сборке данные.
Порядок слоёв не поможет следующему одноразовому builder найти локальный кэш, удалённый вместе с предыдущим. Для него проверяются импорт и экспорт внешнего BuildKit-кэша, включая стоимость передачи. Эти механизмы описаны в руководстве Docker. Секреты передаются механизмом секретов сборки, без копирования в слой. Git-метаданные исключаются из контекста только если сборка обходится без них.
Не перегрузить исполнителя параллельными заданиями
После изменения графа очередь может сократиться, а тесты стать медленнее. Несколько контейнеров с базами данных распаковывают файлы на один физический накопитель. CPU, память и сеть тоже общие. Разница между отдельным быстрым запуском и серией под обычной нагрузкой покажет, насколько выгодна новая параллельность.
В конфигурации GitLab Runner concurrent ограничивает общую параллельность экземпляра, limit отдельный runner, request_concurrency одновременные запросы заданий. Это разные ограничения. Изменение числа запросов не добавляет ресурсов машине.
Тестовые шарды делятся по истории длительностей, а не по одинаковому количеству файлов. Самая тяжёлая группа определит окончание этапа. Каждому запуску нужны собственные порты, каталоги и данные, иначе конфликт добавит повторную попытку. При сравнении учитываются и соседние проекты, которые используют тот же хост.
Выделенный сервер обоснован, когда замеры показывают конкуренцию за CPU, RAM или диск. По ним же определяются требования к машине. Если задание ждёт подходящего тега либо ответа внешнего registry, быстрый локальный NVMe не устраняет эту причину задержки.
Принять изменение по серии запусков
Для одной гипотезы меняется один механизм. Одновременная замена машины, кэша и шардов покажет общую разницу, но скроет вклад каждой правки. В отчёте остаются медиана, число наблюдений, p95, медленные trace и суммарные runner-минуты. На небольшой выборке p95 нестабилен. Отказы и повторы flaky-тестов включаются, поскольку на них тоже ушло время.
У production может быть намеренная очередь. Resource group последовательно допускает задания к общему ресурсу и защищает от конфликтующих выкладок. Для устаревших проверок ветки подходят auto-cancel и interruptible, если работа безопасно прерывается. Для миграции данных это свойство требует отдельной процедуры.
Перед слиянием проверяется следующий набор условий:
Обязательные тесты есть в merge request и релизе, их обнаруженное количество не уменьшилось.
Артефакты относятся к нужному коммиту, пустой кэш не ломает сборку.
Фильтры путей учитывают изменения общих библиотек и конфигурации.
Выигрыш сохраняется при обычной нагрузке вместе с очередью и повторными попытками.
Быстрый зелёный статус после исключения обязательного теста не подтверждает ускорение проверки.
В задаче на изменение CI стоит сохранить короткую запись: какой интервал задерживает результат, какой механизм меняется и с чем будет сравниваться новая серия. Тогда сокращение установки на минуту не потеряется внутри общего графика, а более короткая очередь не скроет замедление тестов. Если опыт не подтвердил гипотезу или помешал соседнему проекту, настройка возвращается вместе с сохранёнными измерениями.
Показать полностью
2