На каждую атомную станцию в СССР имелся свой город‑спутник — город для атомщиков. Строить и проектировать его начинали обычно раньше и активнее станции. Таким спутником ЧАЭС стала Припять. Планировать застройку будущего города начали в 1967 году. Через пару лет бумажной работы появился посёлок для рабочих и 4 февраля 1970 г. официально был основан населённый пункт, ставший через 9 лет городом. Припять быстро росла и вскоре её можно было назвать образцовым советским атомградом: качественные здания, большое количество мест досуга, проработанная удобная планировка. Денег на неё не жалели. За 15 с копейками лет существования настроить успели там от души. Что уж говорить, местами Припять превосходила не то что областные центры, но и столицы республик, даже киевскую! Давайте посмотрим, какую красоту погубила авария 26 апреля 1986 года.

Другие статьи цикла:

• Строительство Саркофага. Часть 1. Бетон, гранит и 1000 Р/ч: рождение «Укрытия»

• Строительство Саркофага. Часть 2. Бетонные реки и стальные берега

• Строительство Саркофага. Часть 3. Над развалом реактора

• Демаги в Чернобыле: как немецкие краны строили саркофаг под 1000 Р/ч

• Что творится внутри реактора: история радиационной разведки «Укрытия»

❯ Планировка города

Место, где будет строиться новый атомград, стали искать в 1965 году. Обследовали 16 мест в Киевской, Черниговской и Житомирской областях и остановились на участке у станции Янов на ж/д ветке Чернигов‑Овруч. АЭС и город втиснулись на более‑менее сухой участок на правом берегу Припяти в окружении лесов и болот. Непосредственно к реке город не выходит. С востока к Припяти подходит Яновский затон, на берегу которого и сделали пристань. С севера — озеро Семиходский Старик (старица — участок реки, ставший озером при смене русла), за которым простираются болота до самой Белоруссии. Что любопытно, ж/д станция Семиходы находилась южнее Припяти у самой АЭС рядом с хутором Янов. Село, в честь которого даны были эти названия, было ликвидировано при строительстве города и находилось ближе к станции Янов.

Планировку посёлка рабочих сделали в УралТЭП в 1968–1970 гг. Застраивать собирались пятиэтажными многосекционными (то есть многоподъездными) и девятиэтажными башенными домами. Руководство страны план в целом одобрило, но потребовало снизить стоимость строительства. Тут ещё подоспели новые требования к жилым домам, Минэнерго захотело в 2 раза увеличить мощность ЧАЭС, да и в целом в проекте были недоработки. Но стройка уже шла во всю и потому корректировать план пришлось аккуратно генпланистам и архитекторам Киева и Москвы. Был доработан I‑й микрорайон, сделаны II‑й и III‑й, поселковый центр, зону отдыха, коммунальный центр и базу ОРС (отдел рабочего снабжения). Решено для выразительности построить 12-этажные дома, потом подумали, что гулять так гулять, и добавили к проекту вместо них 16-этажки.

Чтобы добавить красоты городской застройке, выполнили вертикальную планировку (изменение рельефа местности) с минимальными уклонами — 0,5%, то есть на 100 м высота изменится на 50 см. Более плоский рельеф города уже невозможен. Ширина проезжей части улиц — от 8,5 до 16,5 м. Магистральные улицы имели разделительные полосы с озеленением. С учётом тротуаров по 3–4 м шириной, полос озеленения и тому подобного, ширина улиц была огромна — на проспекте Ленина между противоположными пятиэтажками было 100 метров!

Озеленяли город от души. Высажено было 18 136 деревьев (акация белая, липа крупнолистная, каштан конский, тополь пирамидальный, катальпа великолепная, дуб красный, клен остролистный, береза, вяз и тому подобное), 249 247 кустарников (жасмин, сирень, кизильник, бирючина, спирея, шиповник, барбарис, лох серебристый, боярышник и тому подобное). Отдельная гордость — 33 582 куста роз, закупленных в Прибалтике. За зеленью много ухаживали: подсыпали перегной при посадке и плодородную почву, ранее бережно снятую при строительстве и складируемую отдельно, поливали. Вокруг деревьев рыхлили почву и подсыпали удобрения, на зиму утепляли стволы, по весне обмывали кроны хвойных деревьев. Поэтому город так быстро и зарос лесом после аварии.

На 1986 год в Припяти проживало 47,5 тыс. человек, что на треть меньше, чем предусматривалось к 1990 г. Но и на этом доработки планировки не окончились — численность города стремительно росла, а 5-й и 6-й энергоблоки ещё не были достроены. Применили так называемую треугольную застройку: комбинация зданий от 5 до 16 этажей, обеспечивающая хорошую обзорность, освещённость и проветриваемость всем квартирам, минимизируя появление глухих дворов‑колодцев. Кроме первоначально заложенных трёх микрорайонов были отстроены IV‑й и V‑й, возведены промышленные объекты (например, завод «Юпитер»), различные здания и сооружения для учёбы, отдыха и обслуживания населения. Часть зданий и инфраструктуры не были достроены: планировалось проложить троллейбусные пути и открыть два крупных торговых центра, застроить VI‑й микрорайон. Место под него уже засыпали и разровняли, но стройка там так и не началась и площадка была использована под могильник ПВЛРО (пункт временной локализации радиоактивных отходов) «Песчаное плато».

Перед аварией в городе имелось 11 улиц и 2 проспекта:

• Проспекты Ленина и Строителей;

• Улицы Героев Сталинграда, Гидропроектовская, Дружбы Народов, Заводская, Курчатова, Сержанта Лазарева, Леси Украинки, Набережная, Огнева, Спортивная, Энтузиастов.

  Проспект Строителей. Источник фото

❯ Архитектура

На момент катастрофы в Припяти успели отстроить 144 жилых дома с 13 414 квартирами, 16 общежитий (для холостяков на 7 621 место и семейных с 1206 комнатами), 2 гостиницы. Итого площадь всего этого добра составляла 658 700 кв.м. По улицам распределение жилых домов таково:

• ул. Героев Сталинграда: 2 шестнадцатиэтажных дома и 12 девятиэтажных;

• ул. Гидропроектовская: 3 девятиэтажных дома;

• ул. Дружбы Народов: 2 девятиэтажных дома, 5 пятиэтажных домов, 5 общежитий;

• ул. Курчатова: 6 девятиэтажных домов, 9 пятиэтажных домов, гостиница «Полесье»;

• просп. Ленина: 6 девятиэтажных домов, 26 пятиэтажных домов;

• ул. Леси Украинки: 3 шестнадцатиэтажных дома, 21 девятиэтажный дом, 12 пятиэтажных домов;

• ул. Набережная: 1 девятиэтажный дом и 5 общежитий;

• ул. Огнева: гостиница «Ласточка»;

• ул. Сержанта Лазарева: 2 шестнадцатиэтажных дома, 2 девятиэтажных дома, 1 общежитие;

• ул. Спортивная: 12 девятиэтажных домов, 2 пятиэтажных дома, 1 общежитие;

• просп. Строителей: 16 девятиэтажных домов, 2 пятиэтажных дома;

• ул. Энтузиастов: 4 общежития.

Такого количества высотных домов на небольшой площади не было порой в областных центрах. Использовались типовые серии как широко распространённые по всему Союзу, как и локальные проекты киевских архитекторов (например, дома серии БПС-6, развитие московской II-57/17, строившиеся исключительно в Киеве, Украинке и Припяти).

Город был молодой и по строительным меркам, и по демографическим (средний возраст жителей всего 26 лет), посему настроено было много всего для детей. Одних детских садов было 15 на 4 980 карапузов:

• № 2 «Ивушка». Сделан по типовому проекту 2С-04-14. Находится в худшем состоянии из всех, подобно школе № 1, у которой та же конструкция и материалы;

  Здесь и далее (ниже) все фото с сайта Припять Wiki

• № 8 «Теремок». Сделан по одному проекту с № 7;

• № 9 «Звёздочка»;

• № 10 «Чебурашка». Построен по серии 214-2-72;

• № 11 «Сказка». Здание московской серии VI-44;

• № 12 «Василёк». По конструкции копия детсада № 11. Что интересно, расположен забор к забору с детсадом № 9 и школой № 4, которая граничит ещё со «Сказкой». Детский мир какой‑то:)

• № 13 «Золотая рыбка». Принадлежал заводу «Юпитер»;

• № 14 «Малыш»;

• № 15 «Яблонька»;

• № 16 «Радость».

Средних школ было меньше, всего 5, зато вместительных, на 6786 учащихся:

• Школа № 1. Расскажу о ней поподробнее. Она самая старая в городе — построена в декабре 1972 г. по проекту 2С-02-7. Школа стала самым слабым звеном среди крупных объектов города: начала активно разрушаться первой. Конструкция из несущих кирпичных стен, облицованных плиткой, оказалась не самой стойкой. Отлетела плитка, за ней вода и ветер начали выветривать швы кладки, разрушать кирпичи и начали разваливаться перекрытия. Первое такое обрушение в одной игре списали на аномалии. Весной 2013 года от скопившегося мокрого снега рухнула крыша в другом месте. При этом интерьеры сохранились относительно неплохо, но лезть туда сейчас весьма опасно.

• Школа № 3. В неё тоже сохранилось много всего;

• Школа № 4. Большая часть школьного инвентаря была вывезена в Славутич, так как не подверглась радиоактивному заражению;

• Школа № 5. Самая большая (на 1568 человек), сделана по проекту 222-1-278. Не было ни одного выпуска учеников. Считается самой загадочной из‑за полуобчищенного интерьера (часть вещей, как и в № 4, вывезли в Славутич), надписи над входом с цифрами 1, 2, 3, 8 и проломленных стен. Часть мебели стащили в один кабинет.

Кроме всего этого в Припяти были: музыкальная школа, сделанная по типовому проекту 224-2-2 (к слову, очень интересно украшенная); городское профессионально‑техническое училище (ГПТУ № 8) на 600 учеников, Всесоюзный заочный энергостроительный техникум (ВЗЭТ).

Для школьников строили и не успели доделать Дворец пионеров.

Магазинов успели построить 25 штук площадью 9 239 кв.м, в том числе один крупный торговый центр уже действовал и к 1988 году должны были построить ещё два. На тот период этого добра хватало, а поставки товаров были постоянными. Даже если говорить о дефицитных вещах — атомщики своих работников баловали. Купить можно было почти всё, что продавалось тогда в СССР: мебель и посуду, бытовую технику и спорттовары, продовольствие и книги. Самые крупные и, ИМХО, оригинальные магазины:

• Культтовары. Делался в 1984 г. по типовому проекту 272–12-33 площадью 1000 кв.м. Делился на несколько павильонов: в одном продавали различные промтовары, в другом — столовая, в третьем — аптека, в четвёртом — бытовые принадлежности. Недалеко возводился магазин «Детский мир», который так и не доделали.

• Гастроном. Построен в 1977 г. — одним из первых крупных магазинов Припяти. А так — за номером 14.

• Магазин «Книги». Собственно, по названию понятно, что там продавали. Построен между 1979 и 1980 гг. А после аварии отметился тем, что это второе здание в городе, у которого провалилась крыша. По некоторым данным, сейчас уже до половины, но это не точно.

• «Берёзка». Первый в городе магазин (да и вообще один из первых — строить начали в 1972 г.) с самообслуживанием. Желанное место любителей набрать добра и не платить за все покупки. Ходят слухи про то, что это, дескать, был валютный магазин и продавали там всякие джинсы и Кока‑Колу, но, судя по информации от местных жителей — обычный продуктовый. После аварии использовали как склад. Обрушился в 2012 г.

• Мясо рыба овощи (не смешивая тоже можно). Первопроходец припятской торговли — открыли в 1971 г. Выделяется мощнейшей композицией художника Ивана Литовченко на южном фасаде, выполненной в 1977 г.

• «Радуга». Тоже старый магазин. Пристроен был к так называемый «Белому дому» — элитной девятиэтажке улучшенной планировки на прос. Ленина 32/13. Торговали там радиотоварами, автозапчастями и прочей мелочью. На углу — телефонная будка. После аварии тут складировали бытовую технику и вещи, что не сильно подверглись заражению. Обнесли решёткой и даже провели сигнализацию. Добро применяли работники Зоны Отчуждения. Лавочку прикрыли в 2006 г.

• «Струмок» (ручеёк по‑нашенски). Молочный 1973-го года. Ещё один магазин с панно. Плюс — вывеска с неоновой подсветкой.

• Торговый центр. Построен за год до аварии и имеет две части: ресторан и супермаркет с товарами для дома и аптекой. Чтобы удобно было доставлять товары в помещения второго этажа, сделали грузовой лифт. Располагается в самом центре города.

• Универмаг. Один из первых магазинов города (1973 г. постройки) и долгое время (относительно истории Припяти) был единственным не продуктовым. Продавали тут дефицитные товары, в т.ч. пресловутые джинсы, остатки которые ещё находят туристы. В отличие от других магазинов‑одногодок с металлическим каркасом сейчас находится в более‑менее живом состоянии.

И немного пробежимся по некоторым уникальным и не особо объектам:

• Центральный городской стадион «Авангард». Делался для местной футбольной команды «Строитель», 2000 зрителей и для проведения различных спортивных мероприятий. Как писали в те годы, в городе до трети жителей так или иначе занимались спортом, потому в желающих погонять мяч или посмотреть на это дело хватало. Успели построить, но вот открыть собирались на майских праздниках. Применяли его в итоге как посадочную площадку для вертолётов во время ликвидации аварии.

• Спортивный комплекс «Строитель». Известен ещё под именем «Авангард». Построен в 1981–1982 гг. всё для той же одноимённой команды. В нём занимались тяжёлой атлетикой, футболом, баскетболом, волейболом, хоккеем, самбо, карате, настольным теннисом, вольной борьбой и шахматами. Спорткомплекс принимал международные соревнования.

• Автостанция. Припять хоть и не была Усть‑Тьмутараканью, но и не являлась транспортным узлом, как пишут порой. Тем не менее, общественный транспорт был сильно развит. Числилось 167 автобусов. На станцию, построенную в 1972–1973 гг., за сутки могло приходить до полусотни пригородных и междугородных автобуса.

• Горком. Центр управления атомграда был построен в 1977–1979 гг. Кроме горкома КПСС тут находились горисполком Припяти (городская администрация), горком ЛКСМУ (Ленинский Коммунистический Союз Молодёжи Украины), отдел КГБ, ГОРОНО (отдел образования) и ЗАГС. После аварии до 00-х использовался для нужд ликвидаторов.

• Дерево Дружбы народов. Наверно, самый известный арт‑объект города. На стальный столбах закреплены щиты с гербами республик СССР. Ирония судьбы: дружбы народов нет треть века, а памятник даже сейчас находится в отличном состоянии.

• Комбинат бытового обслуживания (КБО). Построен в 1974–1976 гг. для оказания различных услуг населению. В нём были аптека, пошивочное ателье, пункт проката, парикмахерская, бюро добрых услуг.

• Дом быта «Юбилейный». Здание 1981 г. опять же для оказания разных услуг горожанам, но в большем объёме, чем КБО. Конструкция типовая, серии 282-1-82, подобные кубики строились и в других городах СССР. Автору довелось у себя в городе полазить по такому.

• Колесо обозрения. Ещё один символ Припяти. Как и «Авангард», открыть не успели, только пару раз крутили в рамках тестирования и сдаче в эксплуатацию. В 2017 г. туристам удалось таки запустить аттракцион на короткое время.

• Бассейн «Лазурный». Здание 1981 г., кроме самого бассейна имело небольшой спортзал. По стечению обстоятельств оказался в очень чистом месте и фон там ниже, чем местами вне Зоны отчуждения. Использовался по назначению ликвидаторами и рабочими ЧАЭС до 1998 г., когда закрылся из‑за нехватки финансирования.

• Гостиница «Ласточка». Строилась в 1979–1981 гг. при профилактории. Фактически — сделали виллу для приезжающего на ЧАЭС начальства. В отличие от предыдущего объекта попала в пятно сильного заражения и потому вещи, которые обычно из таких объектов были вывезены и захоронены в могильнике, остались в здании.

• Гостиница и ресторан «Полесье». Ещё одно из самых известных мест города. Строилась по типовому проекту 284-5-12 на 108 мест. В процессе строительства вносили изменения, например, добавили этажей, изменили отделку и собирались сделать на крыше летнее кафе, но остановились на смотровой площадке. В эксплуатацию ввели поздней осенью 1978 г. После аварии использовали как дозиметрический пост и ЦУП вертолётов. Сейчас находится в аварийном состоянии и, возможно, скоро обрушится крыша.

• Медсанчасть (МСЧ-126). Крупный медицинский центр, так и не достроенный до конца (не успели закончить, как минимум, хирургической отделение). Построена по типовому проекту 254-1-20 в 1974–1976 гг. Здесь располагались поликлиника, детское отделение, стационар, неврологическое и инфекционное отделения, роддом, морг, молочная кухня, пищеблок, хозяйственный блок, гараж, прачечная и насосная. Сюда же привезли первых пострадавших в аварии и скинули их вещи в подвал. Они лежат там до сих пор и некоторые гении лазают туда, хотя радиация всё ещё слишком высока.

• Статуя Прометея. Установлена возле одноимённого кинотеатра в 1977 г. Являлся и до аварии символом города: атомная станция, как и греческий герой, несла огонь и энергию людям. В 1989 г. перенесена к ЧАЭС для защиты от мародёров.

• Кинотеатр «Прометей». За основу был взят проект 264–13-53 с творческой доработкой архитектором Власовым. Имел два кинозала на 400 и 600 м и буфет. Построен в 1972–1973 гг. Долго (опять же, относительно истории города) был центром культурной жизни Припяти, вокруг по вечерам гуляла молодёжь после киносеансов.

• Дворец культуры «Энергетик». Ещё один доработанный типовой проект, 2с-06-9/70. Здание на 800 посетителей построено в 1978–1979 гг. Сюда уместили кинозал, библиотеку, спортивный зал, небольшой бассейн, секцию бокса.

• Завод «Юпитер». Построен в 1980 г. Был филиалом киевского завода «Маяк» и занимался, как и большинство предприятий тогда, выпуском продукции и военного и мирного назначения. По первому назначению делал электронику для авиации (что точно неизвестно), по второму — детали для бытовой техники. Заражение словил немного и потому, после дезактивации, до 1996 г. в его цехах работало предприятие «Спецатом», занимавшееся разработкой дозиметров и роботов для АЭС.

Припять не была, конечно, каким‑то городом будущего, но, как видим, для комфортной жизни в ней были созданы (и создавались ещё) все условия. В целом — это был типичный советский молодой город со своими особенностями из‑за богатых покровителей в виде атомщиков и чиновников из расположенного рядом Киева. Денег в её строительство не жалели, хотя, судя по всему, местами всё‑таки экономили.

P. S. Как строителю больно смотреть, как после аварии с невидимым врагом‑радиацией постепенно разрушается такой хороший город. Хочется пожелать коллегам, чтобы они не стали свидетелями такой безрадостной гибели своих детищ.

Список источников:

• Припять Wiki;

• ЯСталкер;

• Опросы бывших жителей города.

Представим некого разработчика, который по выходным делает собственный пет-проект. Сначала всё живёт на одной виртуальной машине. Проект небольшой, поэтому вся инфраструктура находится там же. API, база данных, обработка запросов и фоновые задачи. На этом этапе всё просто, а нагрузки почти нет.

После завершения разработки MVP версии, этот разработчик решил показать проект своим друзьям и знакомым.

Проект многим понравился, да настолько, что пользователи начали неконтролируемо расти, только за счёт рекомендаций других пользователей.

Инфраструктура та же. Одни пользователи загружают файлы, другие активно работают с сайтом, третьи ждут ответа, чтобы получить результат.

Сервер начинает отвечать медленнее. В логах появляются тайм-ауты, очередь растёт и сервер просто захлёбывается от наплыва задач, которые не может обработать.

Первая мысль, это улучшить код. В основном помогает, но не спасает от слабого сервера, на котором запущен проект.

Логично подумать: «Просто арендую сервер помощнее».

Опять же, это может помочь, но не всегда. Запросы распределяются честно, а работа нет. Один запрос отвечает за десятки миллисекунд, другой несколько минут.

В этой статье разберём, какие подходы используют крупные компании, и как я решил эту задачу в своём проекте.

❯ Когда одного сервера становится мало

Нагрузка бывает разной

Представим сайт с публикациями, комментариями и загрузкой файлов. Запрос на открытие страницы обычно короткий. Backend сходил в кэш или базу данных и вернул ответ.

А генерация отчёта, изменение размера изображения или конвертация большого файла могут занимать секунды и минуты.

Есть и третий класс работы, операции ввода-вывода и вызовы внешних API.
Они могут упираться не в процессор, а в скорость сети, диск или чужие лимиты.

Пока запросов мало, один процесс может принять обращение, сходить в базу, прочитать файл и вернуть результат.

С ростом потока возникают очереди ожидания. Часть из них видна разработчику. Например очередь фоновых заданий. Другая часть скрыта внутри операционной системы, пула соединений к базе, диска или внешнего API.

Поэтому фраза «сервер тормозит» бесполезна без уточнения.

Сначала нужно найти ресурс, который не успевает обслуживать работу:

• CPU или память;

• база данных и её пул соединений;

• диск или сетевой канал;

• внешний сервис с медленными ответами или лимитами.

Масштабировать систему можно по-разному

Есть 2 подхода по увеличению производительности:

1. Горизонтальное масштабирование — это добавить ещё одну машину или процесс той же роли. После этого появляются новые вопросы: кто выберет сервер, где хранить состояние, как синхронизировать данные и что произойдёт при падении одного узла.

2. Вертикальное масштабирование — это взять более мощную машину. Добавить CPU, память, быстрый диск или GPU. Приложение почти не меняется, поэтому для небольшого проекта это хороший первый шаг. Ограничения тоже понятны: у машины есть предел, а при её отказе приложение остановится целиком.

Оба подхода бесполезны против общего узкого ресурса. Если все серверы приложения обращаются к одной перегруженной базе, новая машина только увеличит давление на неё.

❯ Что насчёт асинхронности?

Асинхронность часто называют лекарством от медленного сервера, что в большинстве случаев действительно так и есть. Но точнее будет сказать, что это способ не тратить поток исполнения на бесполезное ожидание.

Примеры выше, я приводил на основе того что код проекта является синхронным.

В синхронной модели обработчик ждёт завершения операции.
Если он читает медленный диск или ждёт внешний HTTP-ответ, конкретный поток занят ожиданием. В асинхронной модели приложение может отдать управление event loop циклу событий, который переключается между операциями, пока одна из них ждёт сеть или диск, и принять другой запрос.

Например, API принимает запрос на построение отчёта, сохраняет описание работы и сразу возвращает идентификатор. Отдельный процесс забирает фоновые задачи из очереди.

Пользователь не держит HTTP-соединение открытым несколько минут, а API продолжает отвечать на короткие запросы.

Асинхронность не ускоряет вычисление само по себе. Если внутри event loop запустить длительный расчёт на CPU, этот поток всё равно будет занят вычислениями. То же касается и GPU. Асинхронная оболочка не создаёт второй GPU и не увеличивает объём его памяти. Для такой работы нужен отдельный процесс или worker, а число одновременно запущенных задач приходится ограничивать.

❯ YouTube: как Google экономит магистральные каналы

Большая часть нагрузки видеосервиса — это не вычисления, а передача файлов. Если каждый просмотр обслуживать из одного центрального дата-центра, популярный ролик придётся снова и снова отправлять по магистральной сети.

Когда вы открываете видео на YouTube, файл не обязательно летит через полмира из центрального дата-центра Google. Значительная часть контента хранится на серверах, которые физически находятся внутри сети вашего провайдера или рядом с ней. Это и есть Google Global Cache (GGC).

Google Global Cache

Суть этой технологии простая: если сервер с видео находится внутри сети провайдера, то трафик остаётся локальным и не нагружает внешние магистральные каналы. Так же когда сервер находится за границей, провайдер вынужден тянуть тот же объём данных через платные транзитные линии. GGC помогает решить эту проблему.

Два режима кэширования:

• Реактивный: контент попадает в кеш после нескольких запросов от пользователей. Например, после 5-10 просмотров одного ролика в сети провайдера он закрепляется на локальном сервере, и следующие зрители получают его оттуда.

• Превентивный: самые популярные видео заранее загружаются на кеш-серверы, независимо от того, сколько раз их уже смотрели в конкретной сети. Это позволяет отдавать видео без задержек.

Что именно он кэширует?

GGC обслуживает не только YouTube, но и другие статические сервисы.
Google карты, Chrome, картинки из поиска и т.д.

Для YouTube в первую очередь кэшируются сами видеопотоки и превью.

Типичная оценка Google: 70–90% кэшируемого трафика можно отдать с узла, hit rate зависит от того, что смотрят абоненты.

Если GGC отключить, запросы на видео пойдут напрямую к удалённым серверам Google. Это увеличит задержки, ухудшит качество воспроизведения и повысит нагрузку на магистральные каналы.

Внутри YouTube нет «одной программы». Это набор микросервисов: рекомендации, поиск, метаданные роликов, комментарии, реклама и т.д. Когда вы открываете главную страницу, один сервис делает десятки внутренних RPC-вызовов к другим, чтобы собрать всё воедино. Каждый из этих сервисов запущен в сотнях реплик, поэтому перед каждым вызовом нужно решить, на какую реплику отправить запрос.

Для этого компания Google разработала Prequal (Probing to Reduce Queuing and Latency). Её цель не «уравнять загрузку CPU», а минимизировать реальную задержку запросов и избежать очередей, особенно в хвосте распределения.

Prequal

Вместо того, чтобы балансировать по средней загрузке процессора, Prequal выбирает реплику по двум сигналам.

• RIF (Requests In Flight): сколько запросов прямо сейчас обрабатывается на реплике. Это мгновенный показатель, который хорошо предсказывает будущую нагрузку и потребление памяти.

• Оценка задержки: медианная латентность недавно завершенных запросов при похожем уровне RIF.

Реплика выбирается по определенным правилам.

Сначала, клиент оценивает распределение RIF по всем репликам и помечает зонды:

• «горячие» (hot): RIF выше выбранного квантиля (например, выше 80–90% реплик).

• «холодные» (cold): остальные.

Если в пуле есть хотя бы один «холодный» зонд, выбирается холодный с наименьшей задержкой. Если же все зонды «горячие», то выбирается тот зонд, где RIF имеет меньшее значение.

Эти правила отражают приоритеты. Главное, не допустить, чтобы реплика ушла в перегруз по памяти и числу активных запросов. А второе, это минимизировать задержку.

Зонды Prequal отправляются асинхронно. Текущий запрос использует данные от зондов, запущенных предыдущими запросами, чтобы не добавлять задержку на критический путь. Каждый зонд переиспользуется несколько раз, но не бесконечно. Старые записи удаляются по возрасту, по лимиту переиспользования и через периодическую чистку «худших» зондов, чтобы пул не смещался в сторону перегруженных реплик.

Почему отказались от WRR

Почему prequal лучше старой реализации балансировки по CPU (WRR) ?

До внедрения Prequal, YouTube (и многие другие сервисы Google) долгое время использовался балансировку по CPU на основе Weighted Round Robin (WRR).

Её базовый принцип: каждая реплика получает «вес» пропорционально своей средней утилизации процессора, и запросы распределяются по репликам циклически с учётом этих весов, чтобы в среднем нагрузка по CPU была примерно одинаковой.

WRR хорошо выравнивал среднюю загрузку CPU, но плохо реагировал на короткие всплески и «несчастливые» реплики. Это приводило к росту очередей, увеличению хвостовых задержек и периодическим таймаутам на чувствительных к латентности сервисах.

Даже при «нормальной» средней утилизации CPU отдельные реплики регулярно уходили в перегруз из-за конкуренции с другими процессами на той же машине. Балансировка по CPU не успевала это фиксировать и продолжала направлять запросы на уже перегруженные узлы.

Prequal сместил фокус с «средней утилизации CPU» на реальную задержку и число активных запросов. Это позволило быстрее обходить проблемные реплики, сократить хвостовые задержки на 40–50% и практически устранить ошибки из-за дисбаланса нагрузки, что и стало причиной перехода.

❯ Яндекс Диск: как избежать двойной нагрузки на сеть

Обычный балансировщик принимает запрос пользователя и пересылает его на один из серверов. Для небольшого ответа это нормально. С большими файлами возникает лишняя работа. Балансировщик сначала принимает весь файл, а затем передаёт те же данные серверу хранения. Сеть используется дважды.

При загрузке файлов на Яндекс Диск трафик идёт через промежуточное звено, которое не хранит данные, но вынуждено пропускать через себя гигабайты. Это создаёт узкое место. Балансировщик тратит ресурсы на передачу чужих данных, а сеть нагружается вдвое сильнее, чем нужно.

Разделение Control- и Data-запросов

В Яндекс Диске этот путь разделили. Сначала клиент отправляет маленький управляющий запрос и спрашивает, куда загружать файл. В ответ получает ссылку на конкретный сервер и передаёт данные сразу туда, минуя промежуточный балансировщик.

Компонент, который выбирает сервер, в Яндексе назвали Балансерун. Сервер-приёмник получил имя Кладун. Балансерун знает список доступных Кладунов, следит за их состоянием и возвращает пользователю ссылку на один из них.

Основная суть:

• Control-запросы: лёгкие HTTP-запросы для получения адреса загрузки. Они проходят через стандартный балансировщик, так как почти не создают сетевой нагрузки.

• Data-запросы: сами файлы, которые идут напрямую от клиента к выбранному Кладуну, минуя балансировщик.

Это снимает двойную нагрузку на сеть. Данные больше не проходят через промежуточное звено.

Почему не подходят Random и Round Robin

Оба алгоритма распределяют запросы, но не учитывают реальную скорость загрузки:

• Random: случайный выбор узла. При высокой дисперсии скоростей пользователей (от 10 Мбит/с до 1 Гбит/с) некоторые узлы получают несколько «тяжёлых» клиентов подряд и перегружаются, пока другие простаивают.

• Round Robin: чередование узлов. Даёт равное число запросов, но не равный трафик. Один узел может получить трёх быстрых клиентов, другой, трёх медленных.

В обоих случаях нагрузка на сеть распределяется неравномерно, возникают «хвосты» перегруженных узлов.

Решение проблемы: HOBA

Для решения этой проблемы каждый Балансерун получает собственную группу серверов. Выдав ссылку пользователю, он сразу увеличивает расчётную нагрузку выбранного Кладуна на ожидаемую скорость загрузки. Ждать следующего отчёта от сервера не нужно. Периодические общие показатели лишь исправляют накопившуюся ошибку прогноза. В Яндексе этот алгоритм назвали HOBA (Hierarchical Optimized Balancing Algorithm).

Как это работает:

• Локальные пулы. Каждый Балансерун получает непересекающийся пул Кладунов. При назначении загрузки он мгновенно обновляет виртуальную нагрузку выбранного узла на ожидаемую скорость клиента, не дожидаясь отчётов. Это даёт актуальную «картину мира» в ту же миллисекунду.

• Учёт скорости. Балансировщик хранит данные о скорости пользователя (текущей, средней по истории или медианной по системе) и оперирует прогнозируемой нагрузкой на канал, а не числом запросов.

• Глобальная статистика. Периодические отчёты от Кладунов (раз в K секунд) теперь используются не для мгновенных решений, а для коррекции накопленной погрешности локальных расчётов. Это позволило увеличить интервал K и разгрузить шину управления.

Rendezvous Hashing: стабильное распределение пулов

Остаётся понять, какой Балансерун отвечает за какие серверы. Для каждого Кладуна все балансировщики независимо вычисляют одного и того же владельца. Если Балансерун исчезает, переназначаются только его серверы. Этот метод называется Rendezvous Hashing.

Принцип работы:

1. Для каждой пары «Кладун + Балансерун» вычисляется весовая функция.
2. Кладун назначается в пул того балансировщика, у которого вес максимален.
3. Если один Балансерун падает, пересчитываются веса только для его Кладунов — остальные пары сохраняют свои веса и остаются в прежних пулах.

Это минимизирует миграции и сохраняет локальную статистику на живых балансировщиках.

Ограничение размера пулов

Чтобы случайность не отдала одному Балансеруну слишком много Кладунов, размер каждой группы дополнительно ограничивается:

• Вычисляется «идеальный» размер пула: uploaders_num / balancers_num.

• При назначении Кладуна проверяется, не достиг ли пул балансировщика лимита. Если да, выбирается следующий по весу балансировщик.

• Дополнительно можно ограничивать пул снизу, чтобы разница между наиболее и наименее заполненными пулами не превышала единицы.

После внедрения HOBA распределение загрузки сети стало более равномерным. Стандартное отклонение снизилось на 22%, количество перегруженных «хвостов» уменьшилось, а утилизация сети выровнялась. Алгоритм особенно эффективен при высокой дисперсии скоростей пользователей.

❯ Timeweb Cloud: не запустить всё сразу

Иногда физический сервер нужно освободить для ремонта или замены. Запущенные на нём виртуальные машины переносят на другие серверы. Если начать десятки таких миграций одновременно, они займут весь сетевой канал и помешают не только друг другу, но и работающим клиентским машинам.

Внутренний сервис Timeweb Cloud под названием vapi-server сначала измеряет доступную скорость между исходным и целевым сервером. Затем он решает, сколько виртуальных машин можно переносить одновременно, и делит между ними канал. Новая миграция начинается, когда освобождается место.

Принцип:

1. Если запустить все миграции сразу, они «забьют» сеть, и каждая будет идти медленно, мешая остальным.

2. Если ограничить число одновременных переносов и разделить канал, миграции пройдут быстрее и не повлияют на работу клиентских машин.

Решение: агенты на гипервизорах

При создании виртуальных машин используется другой подход. Физический сервер, на котором запускаются виртуальные машины, называется гипервизором. Раньше команды для всех гипервизоров проходили через центральный API и образовывали длинную общую цепочку.

Теперь на каждом гипервизоре работает небольшой служебный процесс или агент. Центральный API сообщает, что нужно сделать, а агент выполняет команду на своей машине и возвращает результат. Несвязанные операции могут идти параллельно.

Как это работает:

• Центральный API: принимает запросы от пользователей и распределяет задачи между гипервизорами.

• Агент на гипервизоре: получает команду, выполняет её локально (создание ВМ, старт, остановка) и возвращает результат.

Это убирает узкое место в виде единой очереди и позволяет выполнять независимые операции параллельно. Похожую логику можно использовать не только внутри облачной платформы, но и при построении собственной инфраструктуры.

Как взять этот принцип и применить у себя

Похожий подход можно использовать и при настройке пользовательской инфраструктуры.

Например, проект можно разместить на нескольких облачных серверах Timeweb Cloud, а входящий трафик распределить между ними с помощью балансировщика нагрузки.

Вместо одной машины, которая принимает все запросы, нагрузка разделяется между несколькими серверами. Если проект растёт, к схеме можно добавить новый сервер и направить на него часть трафика. Балансировщик также проверяет доступность подключённых машин и исключает из распределения те, которые перестали отвечать.

Такой сценарий позволяет постепенно расширять инфраструктуру. Начать с двух серверов, а затем добавлять новые ресурсы по мере роста нагрузки. Серверы создаются через панель Timeweb Cloud.

Здесь используется тот же общий принцип, что и во внутренней инфраструктуре Timeweb Cloud. Не отправлять все операции или запросы одному исполнителю, а распределять нагрузку между несколькими доступными ресурсами.

Что дала новая архитектура

В июльском дайджесте Timeweb Cloud указывает результат этой перестройки. Что от нажатия кнопки до готовой виртуальной машины проходит около 30 секунд.

Такой подход работает не только внутри платформы. Когда вы разворачиваете проект на облачных серверах Timeweb Cloud, аналогичные принципы применяются и к вашей инфраструктуре. балансировщик нагрузки распределяет трафик между несколькими VPS, а новые виртуальные машины создаются за секунды через API или панель управления.

В одном случае компания распределяет команды между локальными исполнителями. В другом ограничивает число одновременных переносов реальной скоростью сети. Это внутренняя инфраструктура Timeweb Cloud, а не описание балансировщика, который предлагается пользователям.

Для гипотетического разработчика из начала статьи как раз этот слой и нужен. Две-три машины, балансировщик между ними, без собственного мини-Диска. Продукт здесь инструмент в истории, не заголовок.

❯ .sound: пример из жизни

Одна из самых тяжёлых операций выглядит так:
1. Получить аудиофайл.
2. При необходимости отделить вокал через Demucs.
3. Распознать слова с помощью faster-whisper.
4. Сопоставить строки с моментами в аудио.
5. Вернуть текст и тайм-коды в основную серверную часть, или Backend.

Сначала такая обработка выполнялась рядом с основным приложением. В итоге веб-запросы и распознавание музыки конкурировали за процессор, память и диск. Масштабировать весь Backend ради одной тяжёлой операции было бессмысленно.

Я вынес вычисления в отдельный репозиторий.

При его запуске создаётся отдельный worker. Он сам подключается к Backend и просит следующую задачу.
Такой порядок называют pull-моделью. Не сервер ищет свободного исполнителя, а исполнитель приходит за работой.

Благодаря этому, на домашнем компьютере или сервере с видеокартой не нужно открывать входящий порт. Да и нагрузка значительно снижается, ведь распределена между разными серверами.

Разные задачи, разные способы обработки

В «.sound» разные типы задач не складываются в одну общую очередь.

Для каждой группы используется отдельный способ хранения и обработки. Обычные фоновые операции выполняются рядом с сайтом, а ресурсоёмкие вычисления и распознавание аудио обрабатываются отдельно.

Это позволяет задавать для них разные ограничения, правила запуска и повторной обработки.

На архитектурной схеме единая очередь выглядела бы аккуратнее. Но в коде разделение оказалось понятнее. Короткие фоновые задачи, удалённые вычисления и длительная обработка аудио по-разному восстанавливаются после сбоев.

Как исполнители делят задачи между собой

При подключении исполнитель указывает профиль:
cpu_light (обычный процессор) или gpu_full (видеокарта) и какие типы задач умеет брать. Распознавание песен (ASR) обычно ждёт машину с видеокартой.

Сервер (Backend) выбирает работу по типу, приоритету, профилю и времени, когда можно пробовать снова. Если несколько исполнителей тянут одну задачу сразу, PG на короткое время блокирует эту запись. Остальные не ждут, а берут следующую.

Забрав задачу, исполнитель держит её только ограниченное время.
Раз в минуту отдельный фоновый процесс находит просроченные задачи и возвращает их в очередь с паузой перед новой попыткой.

Это не гарантия, что задача физически запустится ровно один раз. После сбоя её могут выполнить снова. Поэтому повторная постановка не должна создавать копии, а повторное сохранение результата, портить данные.

Как Backend понимает, что исполнитель жив

Каждые 15 секунд исполнитель шлёт запрос «я жив» на сервер, и обновляет время последней связи.

И в том же ответе может сказать: не бери новые задачи или отмени текущую задачу.

Почему аудио и остальные задачи выполняются по-разному?

Сложные GPU задачи работают строго по одой задаче. Пока текущая не закончена, следующую не берут.

Остальные вычисления можно делать параллельно. Есть общий потолок и отдельные лимиты по типам.

Что даёт отдельный исполнитель

Тяжёлые задачи больше не живут в том же процессе, который отвечает пользователям. База и выдача музыки отделены от вычислений.

Исполнителя можно перенести на другую машину. Можно добавить несколько исполнителей, чтобы разгрузить очередь. Можно сменить процессор на видеокарту или поставить машины с другим набором задач. Снаружи проект от этого не меняется.

Если исполнитель падает, задание не зависает в статусе «обрабатывается». Когда отведённое время кончается, фоновый процесс возвращает его в очередь. Перегруженную машину можно поставить на паузу: сервер говорит об этом в ответе на очередной пульс.

Про «в десять раз быстрее» писать не буду. Задачи стали обрабатываться быстрее, но траты на аренду тоже выросли. Воркеры живут на отдельных серверах.

❯ Общие принципы

Не чеклист на все случаи, а то, что выявил разбирая примеры выше.

1. Балансируй конкретный ресурс, а не «запросы вообще».
   В примерах выше узким местом оказывался не CPU в целом, а что-то одно: магистральный канал (YouTube), сеть на балансировщике при загрузке файлов (Яндекс Диск), очередь RPC-реплик с разной латентностью (Prequal), канал между гипервизорами (Timeweb), GPU/CPU под тяжёлыми вычислениями (.sound). Прежде чем выбирать алгоритм, нужно определить ресурс который будете оптимизировать.

2. Разделяй короткие HTTP-запросы и тяжёлую работу.
   В .sound тяжёлые задачи вынесены в отдельных воркеров, которые сами забирают задачи. В YouTube тяжёлый трафик вынесен на кэш-узлы у провайдера, в Яндексе data-запросы идут напрямую на узел хранения. Если тяжёлая операция живёт в том же процессе, что и веб-ответы, она будет воровать CPU, память и диск у обычных запросов.

3. Метрика важнее названия алгоритма.
   Google ушёл от WRR (балансировка по среднему CPU) к Prequal, потому что «средний CPU за минуту» врал. Реплики уходили в перегруз по памяти и числу активных запросов, а хвостовые задержки росли. В Яндексе HOBA оперирует не числом запросов, а прогнозируемой нагрузкой на канал с учётом скорости клиента. Выбор метрики (RIF + латентность, нагрузка на сеть, число активных миграций) определяет, будет ли алгоритм работать.

❯ Заключение

Балансировать нужно не абстрактные запросы, а ресурс, который заканчивается.

Масштабирование не начинается с покупки самого мощного сервера или подключения случайного балансировщика. Сначала нужно понять, что именно не справляется: CPU, GPU, сеть, диск, база данных или очередь задач.

У крупных сервисов разные решения, но принцип один. Тяжёлую работу отделяют от коротких запросов, данные стараются не гонять через лишние узлы, а нагрузку измеряют метрикой, которая связана с реальной проблемой.

Для небольшого проекта не нужно копировать инфраструктуру YouTube или Яндекс Диска. На первых этапах достаточно вынести долгие операции в отдельные воркеры, ограничить число параллельных задач и при необходимости добавить несколько серверов за балансировщиком. Инфраструктура должна расти вместе с продуктом, а не опережать его.

Ссылки:

GitHub: https://github.com/network-user

Источники:

YouTube и Google

1. Load Is Not What You Should Balance: Introducing Prequal, NSDI '24.
2. Google Global Cache: overview.
3. Google Global Cache: Cache Fill.
4. Google Global Cache: Content Served.

Яндекс Диск

1. Как Яндекс Диск выдерживает сотни гигабит входящего трафика.

Timeweb Cloud

1. Июльский дайджест: сервер за 30 секунд, новые модели и токены на агента.
2. Transfer 2.0, или Как я перестал бояться и полюбил миграции облачных серверов.

Последний месяц лета закрываем длинным списком релизов для AI-агентов: документация, MCP-сервер, скиллы, навыки, файлы в чате и четыре новые модели в каталоге. Причина простая: каждое третье обращение к нашей документации — от агентов, нужно считаться с новой аудиторией.

Вторая половина выпуска для тех, кто читает сам: три класса хранения в S3, отмена удаления баз, клон приложения в App Platform, домены через Госуслуги и обновленный Kubernetes.

Разворачиваем каждый пункт ниже ↓

❯ Учиться никогда не поздно

Чем больше задач у агента, тем длиннее системный промпт, а значит, каждое обращение к модели обходится дороже. Чтобы не тратить токены зря, инструкции теперь можно разложить по навыкам — отдельным блокам под конкретные задачи.

Каждый навык состоит из трех частей: название, описание «когда применять» и сама инструкция. В запрос уходит только компактный индекс, а полная инструкция подтягивается, если запрос подошел под условие. Как устроены навыки →

Начать просто: возьмите повторяющуюся задачу вроде оформления отчетов, задайте ей условия и подключите к одному агенту или сразу к нескольким.

Отправить своего агента за новыми навыками →

❯ Вашу панель всем бы показать

Не останавливаемся и продолжаем улучшать панель — в августе три уж очень удобных обновления.

1. Режим стримера. Скрывает в панели все, что не стоит показывать в кадре: публичные IP, баланс, ФИО, телефон, емейл, домены и почтовые ящики. Пригодится, когда снимаете скринкаст, стримите работу или демонстрируете панель на созвоне. Включается в меню профиля справа вверху.

2. Избранное. Разделы панели и ваши серверы, базы, приложения теперь можно закрепить в левом меню — они всегда остаются сверху. Если каждый день начинаете с одних и тех же, искать их больше не придется.

3. Больше прав для дополнительных пользователей. Основной аккаунт теперь может открыть коллеге доступ к «Новостям и идеям» — либо только на чтение, либо с возможностью комментировать, ставить лайки и предлагать свои идеи от своего имени. А если у дополнительного пользователя есть доступ к поддержке, уведомления по тикетам будут приходить ему на почту, как и владельцу аккаунта.

Показать свою панель всем →

❯ 1100 токенов вместо 295 000

Документация должна быть понятной не только для людей, но и для агентов. Вот что сделали для этого.

Отдали агентам чистый текст. Добавили на сайт llms.txt и llms-full.txt, а следом MD-версию всей документации. Файлы вышли слишком объемными, поэтому раздробили их на части. Теперь на страницу уходит около 1100 токенов вместо 295 000.

Убрали обрывы на середине. Подняли рейт-лимиты, чтобы серия быстрых запросов не упиралась в ограничение, и настроили кеширование со всеми заголовками, которые агенты ожидают увидеть. Страницы отдаются из кэша, задача доходит до конца.

Свели HTML и MD к одному содержанию. Выровняли разметку обеих версий: агент читает ровно то же, что видите вы, без расхождений и устаревших кусков.

Показать документацию своему агенту →

❯ Три инструмента вместо каталога

Если документация — это руководство, то MCP-сервер — инструмент, чтобы видеть, создавать, менять и настраивать ваши ресурсы. И инструмент тоже должен быть удобным в работе.

Чтобы не раздувать контекст и расход токенов, мы свели все возможности Timeweb Cloud MCP к трем инструментам:

search_tools — найти нужную операцию по описанию задачи

get_tool_definition — получить ее параметры

execute_tool — выполнить операцию с этими параметрами

Агент больше не держит в памяти весь каталог, а ищет нужное под конкретную задачу. Контекст остается компактным при любом числе методов — поэтому список доступных действий мы смогли заметно расширить. Как подключить MCP-сервер →

А в пару к нему выложили репозиторий со скиллами — готовыми инструкциями, как поднять сервер, настроить DNS или посмотреть баланс. В Claude Code скиллы ставятся как плагин двумя командами, в Cursor, Codex и OpenCode — через npx skills. Забрать скиллы с GitHub →

Дать агенту порулить облаком →

❯ Данные разные — и лежат по-разному

Данные в S3 бывают разные: к одним обращаются каждую минуту, другие годами лежат про запас. Поэтому расширили количество классов хранения в S3 — теперь при создании нового бакета можно выбрать один из трех вариантов.

Премиальный — с тройной репликацией и повышенной производительностью. Подойдет для данных, которые постоянно читают и записывают.

Стандартный — для файлов, к которым обращаются регулярно, но высокая скорость доступа не критична: пользовательских загрузок, медиа и рабочих выгрузок.

Холодный — для архивов, бэкапов и датасетов, к которым возвращаются раз в редко.

Уже созданные бакеты работают на прежних условиях — переносить и пересчитывать ничего не нужно.

Разложить данные по классам →

База, у вас отмена:

Удалить кластер по ошибке проще, чем кажется: во время наведения порядка или выполнив команду не в том окне. У облачных серверов на этот случай уже есть отмена удаления, теперь такая же появилась у баз данных.

С подключенной защитой удаленный кластер не исчезает сразу: он хранится еще 72 часа, и все это время его можно вернуть — с данными, резервными копиями и конфигурацией. Восстановление бесплатное, для всех типов баз и во всех регионах. Условия и порядок восстановления →

Стоимость — 200 ₽ в месяц за одну базу. Если защита не подключена, разовое восстановление стоит 2000 ₽.

Подключается в настройках кластера → «Бэкапы» → «Отмена удаления». У новых кластеров можно включить сразу при создании.

Подстелить базе соломки →

❯ Одно приложение хорошо, а два — лучше

Теперь приложение в App Platform клонируется так же, как облачный сервер. Выбираете нужное, жмете значок справа, проверяете параметры.

По умолчанию все как у исходного приложения. Поменять можно ветку и коммит, конфигурацию с регионом и тарифом, приватную сеть, название, комментарий и проект. Переменные окружения, директория и команда сборки переносятся сами.

Где может пригодиться:

Пользователи в другом регионе. Разворачиваете копию ближе к ним и снижаете задержки.

Подбор конфигурации. Поднимаете клон на других ресурсах и сравниваете с оригиналом — рабочее приложение при этом не трогаете.

Резерв. Держите копию в другой локации и переводите на нее трафик, когда нужно.

Сделать приложение-близнец →

❯ Веб-сервер настраивается в приложении

Запрос от пользователя попадает в приложение не сразу — сначала его встречает веб-сервер. Теперь его параметры настраиваются прямо в приложении.

Редиректы. Перенаправление с одного пути или домена на другой. Пригодится, когда меняете структуру адресов или переезжаете на новый домен и не хотите потерять поисковый трафик.

HTTP-заголовки. Добавляете, меняете и удаляете заголовки в ответах веб-сервера: Cache-Control, CORS, CSP, HSTS. Служебные вроде Server и X-Powered-By можно, наоборот, спрятать.

Сжатие. gzip или zstd: данных передается меньше, страница у пользователя открывается быстрее.

Обработка несуществующего адреса. Только для фронтенд-приложений — показывать главную, как принято в SPA, или вашу страницу 404.

Лимиты для бэкенда. Максимальный размер тела запроса в килобайтах и таймаут ожидания заголовков ответа в миллисекундах: тяжелые запросы и зависшие соединения не копятся.

Покрутить настройки веб-сервера →

❯ Еще один сертификат

В App Platform, помимо сертификатов Минцифры, появился второй корневой сертификат — от Центра сертификации ТЦИ.

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

Работает для бэкенд-приложений и развернутых из Dockerfile или Docker Compose. Два сертификата друг другу не мешают: включайте оба сразу или только нужный.

Включить второй сертификат →

❯ Два пути, чтобы все найти

Продолжаем парад AI-релизов — у поиска по базе знаний стало два режима.

Классический — как было раньше: перед каждым запросом по базе идет семантический поиск, найденные фрагменты подмешиваются в контекст модели. Предсказуемо и быстро.

Агентный — модель сама решает, когда и что искать: может уточнить формулировку, сделать несколько поисков подряд, собрать ответ из разных частей базы. На сложных запросах вроде «найди все товары из списка в категории X» разница в качестве заметна.

Базы знаний, которые вы подключали раньше, остались в классическом режиме — переключить можно в настройках агента. Для новых подключений агентный выбирается по умолчанию.

Переключить режим поиска →

❯ Агенту можно передать файл

Скриншот с ошибкой, выгрузка в CSV, лог — теперь все это можно отправить агенту двумя способами.

В телеграме. Файл уходит в чат вместе с запросом: агент сделает сводку по CSV или найдет ошибку на скриншоте с логами. Пригодится тем, у кого агент уже стоит в чате поддержки.

Через API. Files API — отдельный механизм для работы с файлами в API агентов, без прежних ограничений по формату и размеру. Схема простая: пользователь вашего сервиса прикрепил файл в чате → сервис передал его агенту через API → агент ответил с учетом содержимого.

Нагрузить агента файлами →

Пополнения в каталоге моделей:

Добавили четыре модели: Qwen 3.8 Max, Gemini 3.7 Flash, Grok 4.6, GLM 5.3 и GLM 5.3 Flash.

А если вы раньше пользовались AI Gateway, но перестали, до конца года на токены всех моделей действует скидка 20% — повод вернуться и сравнить новинки с тем, на чем работали раньше. Подробнее об условиях →

Перебрать каталог →

❯ Идентификация администратора домена через Госуслуги

Для владельцев доменов .ru и .рф в панели появилась идентификация администратора через Госуслуги — она стала обязательной с 1 сентября. Физлица уже могут ее пройти:

В разделе «Домены и SSL» открываете вкладку «Администраторы» и жмете «Подтвердить данные». Проходите проверку через Госуслуги, и если данные совпали, рядом с доменом появляется отметка. Детали уже в документации →

Для юрлиц идентификацию добавим позже. Отдельный случай — домены .su и домены .ru и .рф, зарегистрированные через R01 или Руцентр: их администраторы проходят идентификацию у этих регистраторов.

Подтвердить данные →

❯ Кластер, который можно пересобрать

Начнем с версий: обновили линейки 1.33, 1.34, 1.35 и 1.36.

Дальше — конфигурация воркер-группы. Она больше не фиксируется при создании: у готового кластера можно перейти на тариф выше или на конфигуратор.

А на случай, когда в нужной локации ресурсы кончились, а кластер нужен именно там, сделали предзаказ. Работает и для новых кластеров, и для добавления воркер-ноды в готовую группу или новой группы целиком. Кластер создастся сам, как только ресурсов в локации хватит.

И обновили CSI-драйвер: в комментарий к диску теперь сам записывается его назначение — например, TWC-CSI, Namespace: default, Name: net-drive-demo. Видно, что это за диск и к чему он относится, не заходя в кластер. Комментарий можно изменить.

Пересобрать воркер-группу →

Всё, что о нас говорят:

Вошли в CNews500, рейтинг пятисот крупнейших ИТ-компаний России.

Рассказали про успехи AI Gateway: 70 моделей через единый API и рост числа пользователей на 40% за август. Плюсом, отдельные локальные модели, а также модели для картинок, синтеза и распознавания речи.

Кейс Metamentor появился и в медиа. Напомним, что Metamentor разрабатывает решения на базе генеративного AI для крупных компаний. CNews рассказали, как компания масштабируется на инфраструктуре Timeweb Cloud — за два года их выручка выросла в 32 раза.

❯ Что читали и лайкали

В августе не изменяли нашим принципам — разбирали все самое интересное, необычное и увлекательное. Все для ваших просмотров и лайков.

Каждое третье обращение к нашей документации — от агента. Михаил Шпаков, наш руководитель разработки, разбирает, почему провайдеров скоро будет выбирать агент, что случится с ценами управляемых сервисов и почему проверку работы агента нельзя поручать самому агенту.

Свой видеохостинг вместо чужого. PeerTube на Debian 12: PostgreSQL, Redis, Nginx, Let's Encrypt, Fail2Ban — и вот у вас площадка, которая по ActivityPub здоровается с соседними инстансами вместо того, чтобы жить в одиночку.

Автоматизируем бэкапы с помощью Terraform. Денис Котов, тимлид Core-команды, показывает, как развернуть систему резервного копирования Bareos и управлять ею как кодом. В облаке хранятся настройки, база данных и сами бэкапы, а на сервере клиента остается только агент для передачи файлов. Достаточно указать четыре параметра — остальное система настроит сама.

Altair 8800, Osborne 1 и телефон весом в килограмм. Вспомнили первые компьютер, ноутбук и мобильник. Дорого, тяжело, неудобно и решительно непонятно, кому это надо. Прошло сорок лет, а вопросы все те же.

Возможно, этот выпуск прочитал не только человек. Если вы не AI-агент — ждем от вас лайк и комментарий.

Gothic — серия RPG, которая прошла крайне странный путь к мировой славе. За 25 лет существования она выросла из локального немецкого хита в практически мировую франшизу. Ещё каких-то 10 лет назад за пределами Германии о «Готике» знали разве что в СНГ благодаря трудам локализаторов. И Польше — пожалуй, центре фанбазы серии за пределами её родины (загуглите, сколько польских машиним и контентмейкеров существует — ужаснётесь).

Хоть студия-создатель серии, Piranha Bytes, уже закрылась, её главный хит всё ещё живёт. Благодаря фанатам, создавшим испанскую студию Alkimia Interactive, свет увидел полноценный ремейк первой части «Готики». Он удачно закрепил вторую жизнь франшизы, которую в последние годы разогревали различные ютуберы. Последние привлекли массовую западную аудиторию к «некой странной и хардкорной немецкой RPG.

Делу помогла и общая усталость от западно-американской школы геймдизайна ролевых игр, когда массовые RPG нянчатся с геймером в страхе отпугнуть его минимальными сложностями. На их фоне Gothic кажется новой Dark Souls — что-то необычное, свежее, честное. Что-то, что не держит геймера ни за дурака, ни за ребёнка.

В честь выхода успешного ремейка и общего роста популярности серии я вернулся к ней и освежил в памяти оригинальные части серии. Вместе с этим я решил составить по ней удобный гайд: объяснить, что такое вообще «Готика», в какие части и как правильно играть, и главное — как запустить всё это ретро на современных системах без лишней головной боли.

Если вы на волне хайпа заинтересовались Gothic, но совершенно не представляете что это — этот текст для вас. Всё объясним, расскажем и покажем.

Важная сноска: это гайд для максимально ленивых людей. Здесь не будет подробных прохождений игр дальше самых базовых советов. А способы подружить старые игры с вашими современными машинами — самые прямолинейные и ленивые. Я не фанат хардкорного моддинга, поэтому подобрал самые лёгкие и быстрые решения. Так что не переживайте, образование программиста и долгие часы замены файлов и ковыряний в блокноте вам не понадобятся.
Важная сноска 2: также я не фанат так называемого «васянства». Мы (за рядом редчайших исключений) не будем ставить на игры дополнительный фанатский контент и функции, которых не было в оригиналах, чтобы вы могли получить «тот самый» опыт прохождения. В большинстве случаев будут лишь технические улучшения для вашего комфорта. Захотите добавить в старые игры новые доспехи и мечи от фанатов-любителей — ковыряйтесь уже сами на свой страх и риск.

❯ Что такое Gothic и в какие части серии играть

Gothic — это серия RPG с уникальным, хардкорным и «честным» геймдизайном. Обычно в большинстве ролевых игр западной школы вы — избранный богами или иными обстоятельствами. Любая проблема решается гриндом нужного уровня и хорошего снаряжения. Каждое ваше приключение это полный эмоций аттракцион, а главная сложность в таких играх — найти во взрослой жизни время на их прохождение.

В «Готике» же вы — никто. Буквально: главный герой всей серии это безымянный уголовник, которого в сообществе фанатов так и зовут — Безымянный Герой. Слабый, хилый, без репутации и друзей. Каждую маленькую победу придётся буквально выгрызать у игры. Хотите прокачаться? Удачи победить хотя бы самых первых слабых зверей. Хотите купить какой-нибудь стартовый меч? Вперёд, махать киркой в шахты, чтобы позволить себе обновку.

Никто не даст вам начальный обучающий квест или стартовое снаряжение. Все в мире «Готики» надо заслужить трудом и смекалкой. А для прохождения сюжета придётся выбирать одну из фракций: одиночкой-центристом игру не пройти. Без друзей или как минимум союзников в жестокой вселенной игры делать нечего.

А что за вселенная у «Готики»? Континент Миртана и окружающие его земли — королевство людей в сеттинге мрачного, приземлённого лоу-фэнтези. Эльфов и дворфов здесь нет, драконы прилетают только ко второй части (и это важная деталь сюжета). Зато различных монстров, динозавров и кровожадных орков — больше, чем этого хотелось бы.

Миртане угрожает нашествие орков. Война людей и мохнатых двухметровых зверюг длится многие годы, и человечество сдаёт позиции. Единственное, что помогает держаться — это волшебная руда, которую используют могучие чародеи и из которой куётся магическое оружие и броня верных королю паладинов. Без этого минерала война уже давно была бы проиграна.

В отчаянии король людей, Робар II, сгоняет всех преступников, воров и прочих уголовников на рудники острова Хоринис, где находятся самые богатые залежи руды. Чтобы оттуда никто не сбегал, он приказал придворным магам создать волшебный купол над колонией рудокопов. Он будет впускать людей, но не выпускать. Любой, кто попытается выйти за барьер, будет сожжён магией.

Однако что-то мешает магическому ритуалу. Барьер разрастается больше, чем планировалось, накрывая всю долину рудников вместе с магами и королевской стражей. Каторжники пользуются суматохой, поднимают восстание и захватывают рудники под волшебным куполом, поставив в командование лидеров бунта — рудных баронов под руководством преступника Гомеза.

Создаётся патовая ситуация: королю и всем людям Миртаны нужна руда. Но теперь, чтобы её получить, надо выполнять требования каторжан из долины рудников. Но и те не могут покинуть свою тюрьму — их сдерживает барьер, из-под которого нет выхода. Они навечно заперты в своём маленьком мире-экосистеме в пределах волшебного купола. При этом бароны и верные им люди могут жить в этой клетке как цари, пока у них есть руда на обмен. Ведь терпящий поражение в войне король за нее готов посылать им что угодно, от еды до женщин и дорогого вина.

Вы — лишь очередной новенький преступник, которого сбрасывают в колонию. Из особенного у вас лишь письмо для запертых под куполом магов Огня, которое можно обменять на что-нибудь ценное. Вы ничем не отличаетесь от других бедолаг, попавших на каторгу. И ваша задача не выиграть за Робара II войну с орками, не спасти мир — а выжить и найти способ сбежать из тюрьмы.

Дальнейшие события дают старт более глобальной истории, которая выходит за пределы острова Хориниса. А конфликт из тюремного побега перерастает чуть ли не в войну богов. Но это вы уже узнаете сами, когда сядете проходить «Готику».

Начать знакомство с серией очевидно стоит с первой игры и проходить их по порядку. Однако я бы посоветовал играть не в оригинальную Gothic 1, а ремейк. Первая часть крайне плохо состарилась и, на мой взгляд, сейчас представляет интерес лишь как артефакт эпохи и пример действительно интересного фэнтези-сеттинга. В остальном работает она достаточно паршиво даже с фанатскими патчами, а весь интересный контент кончается в ней буквально после первой главы. Со второй и по последнюю шестую это коридорная игра, где практически нет вызова или интересных решений со стороны игрока. Подай-принеси задания и бесконечная нарезка орков с гоблинами.

В этом плане ремейк лучше буквально в каждом аспекте кроме оптимизации — для игры на Unreal Engine 5 вам понадобится хорошее железо, тогда как Gothic 1 проходима даже на офисном ноутбуке 14-летней давности (я, собственно, на таком и проходил её в 2026 году).

Если вам хочется познакомиться с серией, но не хочется играть во все части, то очевидно стоит играть в Gothic 2. Это общепризнанно лучшая игра франшизы, а знание лора первой части и вселенной в целом не обязательно для того, чтобы стартовать сразу с сиквела. Всё необходимое вы уже знаете из описания выше, а детали того что происходило в колонии и откуда появились драконы вам быстро перескажут в самом начале игры.

❯ Настройка и советы перед игрой

Важно: для всех трёх частей работают чит-коды. Они придутся кстати, если внезапно ваш персонаж застрянет в текстурах, сломается какой-то квест или вы случайно потеряете важный для задания предмет. Это так называемый Marvin Mode. Чтобы включить его, надо выйти в окно характеристик персонажа (обычно это клавиша B или C) и напечатать на клавиатуре «MARVIN». Если в углу экрана появилась надпись о включении «режима Марвина» — вы всё сделали правильно. В этом режиме при нажатии F8 вы будете взлетать в небо, не получая урона от падения. Полезно, если герой застрял или вы хотите попасть в какую-то недоступную точку.

Для использования чит-команд, вызовите консоль на F2 и печатайте нужное. Для создания предметов, например потерянного кольца для задания, введите «insert названиепредмета». Программные имена объектов можно легко найти в интернете, как и другие консольные команды.

Чтобы закрыть режим читов — войдите в окно характеристик и напечатайте на клавиатуре «42».

Ни в коем случае не сохраняйте игру с включённым Marvin-модом. Иначе сохранения могут побиться и не загружаться. Побаловались, выключили режим — и только потом сохранились.

❯ Gothic 1 (вариант для Steam-версии)

Качаем фанатский фикс с GitHub — четыре файла. Для скачки нажмите на синие гиперссылки с названиями нужных файлов во вкладке assets. Запускаем один из двух файлов .exe на выбор. Ваш антивирус может на них жаловаться — не обращайте внимание, вирусов нет. Установочник сам найдёт вашу steam-версию игры. На выбор можете включить настройку геймпада и альтернативную локализацию вместо перевода Snowball.

Этот фикс чинит кучу проблем с совместимостью и тонны багов оригинальной игры. Также он добавляет пару приятных мелочей, которых не было в оригинале — например, алхимию, что полноценно появится только в сиквеле и ремейке. Проводились тесты сборки без этих модов с обычным union-патчем (бренд фанатских патчей для каждой части Gothic), но там было больше глюков, чем в этой сборке. Поэтому я бы посоветовал её.

Установили? Отлично! Это ещё не всё. Идём в папку с файлами игры. Ищем там папку system и файл Gothic.ini. Открываем его блокнотом.

Нас интересуют следующие строки (найти их можно, нажав ctrl+F и введя их название):

playLogoVideos — можете поменять на 0, чтобы сразу запускать игру, минуя логотипы разработчиков при запуске. Опционально.
QuickSaveMode — у вас должна стоять 1. Если всё так, то вы сможете сохраняться в игре на F5 и загружать быстрое сохранение на F9. При игре в любую «Готику» вы обязаны выработать в себе привычку сохраняться после каждого чиха. Выходить в меню и делать ручное каждую минуту слишком накладно (но лучше периодически делать отдельные сохранения чтобы чуть что можно было откатиться к ним). А вот жать быстрое сохранение после каждого значимого действия — удобно и быстро.

Ставим нужные значения и сохраняем файл.

Далее запускаем игру, выбираем вариант Gothic ModFix (один из двух на ваш выбор). Первый вариант это базовый фикс багов, второй — ещё большие правки с нововведениями. Я тестировал и играл во второй.

Начинаем новую игру и пробуем управление или настраиваем его под себя заранее. Я обычно меняю повороты камеры на A и D (шаги в бок вам едва ли понадобятся в геймплее), а на Q-E ставлю действие и что-нибудь боевое (например, блок).

Поздравляю, у вас стоит полностью рабочая версия Gothic в лучшем её виде!

Советы перед игрой:

• Лучшее оружие в игре обычно в руках у каких-нибудь персонажей. Хотите себе самый крутой меч — отберите его у другого каторжника.

• Урон от оружия ближнего боя определяется вашей силой. От дальнего — ловкостью. Минимально вам нужно 30 силы чтобы поднять сюжетный меч в конце игры, для комфортного прохождения достаточно 60-80 очков характеристики.

• В начале игры у вас будут большие проблемы с рудой, местным аналогом денег. По возможности научитесь снимать с монстров шкуры, клыки, зубы и прочее — с их продажи вы сможете заработать себе на стартовое снаряжение.

• Не спешите вступать в первый же лагерь, с которым вам удалось подружиться. Выполните стартовые задания у всех трёх фракций, и только потом уже официально становитесь членом одной из группировок.

• В начале каждой главы проверяйте всех доступных торговцев — обычно лучшее снаряжение можно купить именно у них. Почему-то в первой Gothic исследование подземелий едва ли даст вам что-то ценнее мусора на продажу. Всё лучшее можно или купить, или украсть.

• Лук — это очень здорово. Не игнорируйте лук. Вам понравится стрелять из лука. Нк или из арбалета, но это только с 3 главы в лучшем случае.

• Осторожнее со стрельбой — дальний бой убивает NPC сразу, а не сбивает с ног.

• Во время торговли с другими персонажами вам нужно уравнять свое предложение по цене с рудой или дать больше, чем стоят товары продавца. Вместо того, чтобы перемещать каждый кусочек руды и каждую стрелу по одному, запоминайте управление инвентарём торговли:

  ЛКМ — в количестве 1 единицы предмета;
  Левый ALT + ЛКМ — 10 единиц предметов за раз;
  Левый SHIFT + ЛКМ — 100 единиц предметов за раз.

❯ Gothic 2 (вариант для Steam-версии)

Самая простая для починки часть. Для комфортной игры вам понадобится лишь этот патч и немного работы руками.

Качаем по ссылке выше три файла. Для скачки нажмите на синие гиперссылки с названиями нужных файлов во вкладке assets.

Запускаем файл .exe — он всё делает за нас. Ваш антивирус может на них жаловаться — не обращайте внимание, вирусов нет. Укажите патчу путь до вашей steam-версии игры. Чтобы узнать, где она у вас в системе, в Steam в библиотеке выберите игру правой кнопкой — управление — посмотреть локальные файлы. Скопируйте путь файлов из окна поиска и вставьте в установочник.

Далее проставьте нужные галочки: русский перевод, добавление управления под геймпад если будете играть с него и так далее.

Идём в папку с файлами игры. Ищем там папку system и файл Gothic.ini. Открываем его блокнотом.

Нас интересуют следующие строки (найти их можно, нажав ctrl+F и введя их название):

playLogoVideos — можете поменять на 0, чтобы сразу запускать игру, минуя логотипы разработчиков при запуске. Опционально.
usePotionKeys —  у вас должна стоять 1. Если всё так, вы сможете использовать зелья быстро по нажатию назначенных в настройках клавиш. Возможность их менять появится, только если значение этой настройки поставлено 1. Настоятельно рекомендую это сделать: в отличие от Gothic 1, проходить вторую часть без быстрого «догона» зельями чудовищно тяжело.
useQuickSaveKeys — у вас должна стоять 1. Если всё так, то вы сможете сохраняться в игре на F5 и загружать быстрое сохранение на F9.

Ставим нужные значения и сохраняем файл.

Далее запускаем Gothic 2. Выбираем вариант «Готика 2: Ночь Ворона (обновление)». Это наша пропатченная версия со всем возможным контентом.

В самой игре в главном меню заходим в «настройки обновления». Здесь нужно поставить ряд важных галочек, которые кардинально улучшат ваш опыт прохождения без вреда для «того самого» опыта. Можете просто настроить всё, как на этом скриншоте, и не заморачиваться. Но я всё же поясню, зачем нам это делать.

Удалять ключи: использованные ключи быстро захламляют ваш инвентарь. С этой настройкой дышать будет свободнее. А геймплейной разницы никакой нет между удалением ненужных предметов скриптом или вашими руками.

Быстрая еда: лечение мясом и прочей снедью позволяет экономить на дорогих зельях, но из-за иммерсивных анимаций это может занять слишком много времени. При включении этой функции вы сможете ускорять время в процессе еды. Геймплей это не оказуалит, так как есть в бою, как в Skyrim, вы всё равно не сможете.

Обратный дневник: просто более удобное отображение информации в журнале.

Фокус при отскоке\стрейфе: опционально, настройте под себя. Я оставил по стандарту и не трогал эту настройку.

Платное обучение: в оригинальной игре тренеры учат вас только за очки, что даются за новые уровни. Доплачивать им, как в Gothic 1 Remake не надо. Опционально ради лишнего хардкора. Для первого прохождения не советую.

Честное обучение и свободные бонусы: две важнейшие настроки, которые стоит описать вместе.

У Gothic 2 очень специфический вид прокачки. Дело в том, что каждые 30 пунктов характеристики, будь то сила-ловкость-прочее или навык владения оружием, дальнейшее обучение дорожает на 1 очко обучения. Подобная прогрессия появилась с дополнением «Ночь Ворона», чтобы сбалансировать развитие героя с увеличенным количеством врагов и контента, и как следствие — увеличенным объёмом потенциальных очков опыта.

У этого подхода вылезло две проблемы. Первая: можно сжульничать и сэкономить 4 очка обучения, если докачаться до порога в 29\59\89 очков и использовать у тренера функцию развить навык сразу за 5. Так как игрок ещё не пересёк порог прокачки, повышающий цену, все 5 очков развития рассчитаются по старой цене, а не «1 балл по старой, а остальные дороже». Функция «честное обучение» выключает этот трюк и правильно рассчитывает цены.

Вторая проблема — упор на минмаксинг характеристик. Так как к поздним этапам игры очки прокачки будут тем дороже, чем более развит герой, выгодной стратегией в классическом прохождении «Готики 2» было беречь все перманентные бонусы (зелья, поедание яблок, награды за задания) на самый конец и использовать их только после ручной прокачки у тренеров за очки обучения. Ведь зелье «+3 силы» будет куда выгоднее, если выпить его тогда, когда прокачка 1 балла характеристики будет стоить вам половину нового уровня, а не 1 очко обучения.

Настройка «свободные бонусы» включает рассчёт цены прокачки, который не учитывает любые перманентные бонусы. То есть, питьё зелья силы, поедание яблок и прочие сторонние способы стать сильнее не повлияют на цену прокачки у тренеров. Проще говоря, вы сможете использовать все возможности стать лучше без страха, что потом вам будет сложнее и дороже. Это делает прогрессию плавнее и убирает постоянную тревогу «использовать награду в неправильное время». Я попробовал пройти игру с этой настройкой и теперь не представляю, как можно играть в «Готику 2» иначе.

Лимит боеприпасов\свободные телепорты: уже более «кастомные» настройки, что на мой взгляд портят изначальный баланс и геймдизайн игры. Переключать на свой страх и риск.

Важно: в игре у вас может произойти баг звука, зачастую около водоёмов. Шум воды может заглючить и наложиться сам на себя, что больно бьёт по ушам. Чтобы починить это, попробуйте изменить тип рендера звука в настройках. Подбор нужного под вашу систему обычно чинит эту проблему в большинстве случаев.

Советы перед игрой:

• По возможности каждую главу обходите все доступные локации и вырезайте всех врагов, чтобы при переходе в следующую заспавнилось больше новых монстров и их было проще убивать без помощи от «старичков».

• Дальнобойное оружие работает в игре по особому. Дальность стрельбы и шанс попадания зависит от вашего навыка владения — он не повышает урон. Урон растет от характеристики ловкости. Причём как у лука, так и у арбалета, хотя для владения последним нужна сила. То же самое и для оружия ближнего боя: рапиры и сабли, требующие ловкости для ношения, повышают свой урон от характеристики силы.

• В главный город игры Хоринис можно попасть множеством разных путей. Если хотите веселья и «максимальной эффективности» — попробуйте оббежать его по кругу, уворачиваясь от опасных монстров, и заплыть по морю в городской порт. Получите секретный диалог за вашу смекалку и кучу опыта.

• Как и в Gothic 1, вы можете получить опыт за победу над NPC без нужды убивать последнего. Как только вы наберётесь силёнок, займитесь избиением всех в портовом районе. Стражи там нет, поэтому за драки вас никто не осудит. Ну, кроме тех, кого вы побили. Это отличный источник опыта и стартовых денег с продажи пожитков ограбленных людей. Вы же беглый каторжник, как-никак.

• Осторожнее со стрельбой — дальний бой убивает NPC сразу, а не сбивает с ног.

• При развитии навыка владения оружием на следующее пороговое значение (каждые 30 очков навыка) меняется анимация боя. Любой тип оружия начинает приносить пользу только с «бойца», когда у вас 30 или выше. И если лук и одноручное ещё терпимо на характеристике новичка, то двуручное и арбалет попросту бесполезны без предварительных тренировок. К счастью, при достижении определённого уровня прогресса одноручного оружия\лука потихоньку начинает докачиваться двуручное\арбалет и наоборот.

• Не качайте всё сразу. Вам не хватит опыта, чтобы сделать всемогущего Довакина. Придумайте себе чёткий стиль игры и придерживайтесь его.

• Если захотите играть за полноценного мага — вам придётся выбрать Магов Огня в качестве союзной фракции. Другим путям (Паладин и Наёмник) путь волшебника закрыт. Разве что паладины могут немного пользоваться заклинаниями лечения и нанесения урона нежити.

• Как и в Gothic 1, не спешите сразу вступать в интересующую вас фракцию. Сначала выполните начальные задания у всех, кого можете, и только потом делайте выбор. К счастью, сделать вам это надо лишь для городской стражи\паладинов и наёмников — у магов можно лишь вступить или не вступить, предварительных заданий у них почти нет. Лишь требование в целую тысячу золота и овцу.

• Один раз за прохождение доведите ловкость до 90. Не обязательно, чтобы это значение было перманентным: можете, например, прокачать её до 70 и оставшиеся очки получить, надев специальные кольца и амулет. Как только характеристика достигнет этого значения, вы получите бесплатный перк акробатики, позволяющий прыгать дальше и падать без урона с большей высоты. Если вы хотите стать мастером карманных краж, способным обворовать любого персонажа в игре — вам нужно 120 ловкости.

• В Gothic 2 атаки зверей больше не блокируются: старайтесь не сражаться со всей стаей и уворачивайтесь от укусов отскоком.

• Читайте книги на постаментах. Они дадут вам опыт.

❯ Gothic 3 (вариант для Steam-версии)

Пожалуй, самая сложная к починке часть серии. Но это всё ещё возможно и не так тяжело, как кажется.

Для начала нам нужен руссификатор и community-патч. Последний встроен в бета-ветку лицензионной steam-версии, но у меня почему-то не заработал. Лучше поставить отдельно руками.

Всё необходимое можно достать из этого руководства steam, иначе гугл\нейросети вам в помощь. Идём чётко по инструкции установки до пункта про Questpaket. Это фанатские модификации с любительским контентом, который нам не нужен. Мы хотим оригинальный «ванильный» опыт.

Это базовый «джентльменский» набор, чтобы игра просто работала. С ним я проходил игру примерно в 2020 году без существенных проблем. Однако мы хотим лучший опыт прохождения из возможных. Поэтому пора совершить легендарный подвиг, казавшийся немыслимым ещё 10-15 лет назад — мы починим «Готику 3» полностью.

Качаем Gothic 3 Parallel Universe Patch отсюда (не бойтесь немецкого языка, просто пролистайте страницу вниз и нажмите на ссылку скачки). Эта маленькая заплатка убирает главную техническую беду игры 2006 года (ну, не считая чудовищной горы багов) — невозможность правильно работать с ресурсами процессора, отчего при подзагрузке локации она стабильно даёт неприятный фриз кадровой частоты. С этой маленькой заплаткой игра будет работать в стабильных 100+ FPS без единой просадки, в какой бы угол карты вы не побежали.

Теперь избавляемся от мыльных объектов на расстоянии. Увеличиваем игре дальность прорисовки. Для этого нам понадобится маленький .ini-файл на замену. Достать его можно из этого руководства. В нём также можно посмотреть на разницу стандартной и исправленной дальности прорисовки. Эта заплатка может снизить вам кадровую частоту, поэтому перед установкой посмотрите, как в целом у вас идёт игра. Если у вас очень слабая машина — лучше всё же потерпеть мыльный фон, но играть с комфортным FPS. На моей системе случилась просадка со стабильных 144 фпс до 80-90.

Хорошие новости: в отличие от Gothic 1 и 2, лезть через блокнот во внутренние файлы игры не нужно. И внутриигровые настройки ковырять не нужно (разве что настроить что-то под себя). После устранения проблем выше всё работает из коробки. Наслаждайтесь игрой!

Советы перед игрой:

• Не освобождайте города от орков и не уничтожайте лагеря повстанцев при первой же возможности. Оставьте это на момент поздней игры, когда вы точно исследуете все города или как минимум достаточно прокачаетесь. Освободив 3-4 города или уничтожив пару лагерей повстанцев, вы примелькаетесь лицом и вас будут узнавать как врага сразу же, закрывая возможность выполнить задания этой локации.

• По возможности каждую главу обходите все доступные локации и вырезайте всех врагов, чтобы при переходе в следующую заспавнилось больше новых монстров и их было проще убивать без помощи от «старичков».

• Как и в Gothic 2, атаки зверей нельзя отразить парированием. Отскакивайте и не сражайтесь сразу со всей стаей.

• Попробуйте прыгнуть с большой высоты так, чтобы не погибнуть при падении (например, прыгните со скалы в море). Если вы переживёте долгий прыжок, вы получите скрытый талант акробатики.

• Выучить снятие шкур как можно скорее — всё ещё отличная тактика. Шкуры можно выгодно продать и они нужны по ряду заданий.

• В самом начале игры вы освобождаете от орков город Ардею. Как только вы одержите победу, обязательно заберите из домов и с трупов всё, что сможете. Как только поселение окончательно перейдёт под контроль повстанцев, подбор предметов в его пределах будет считаться за кражу. Поэтому забирайте всё, что к полу не прибито, и обязательно возьмите со стола в центре города руну телепортации.

• В игре прогрессивная система лута в сундуках за исключением пары уникальных ящиков. Внутри всех сундуков в игре — случайная награда, что растет со временем. Чем больше сундуков вы откроете, тем ценнее будет содержимое.

• После боя на мечах врага-гуманоида обычно надо добить, чтобы он умер. Дальний бой убьёт его сразу, а не собьёт с ног.

• Читайте книги на постаментах. Они дадут вам опыт и бесплатно прокачают некоторые навыки.

❯ Мне мало трилогии «Готики»!

Предположим, вы поставили и починили все три главные игры серии («Готики 4» не существует, как и DLC к третьей части, это всё выдумки). Вам понравился немецкий геймдизайн из фракций, шнапса и страданий. Хочется ещё. Вопрос — где достать ещё?

Далее вам стоит попробовать первую Risen. Это, по сути, дополнение «Ночь Ворона», растянутое до полноценной игры с выбором фракций, тропическим островом и своими пиратами среди болот. Risen 2 уже не столько «Готика», сколько игра BioWare, а третья часть и последующие игры Piranha Bytes уже слишком… специфические.

Для первой Risen тоже есть всевозможные патчи, но эта игра уже не такая старая и отлично работает сама по себе. Просто будьте готовы к очень деревянным анимациям и другим особенностям крайне бюджетного АА-гейминга.

Если хочется что-то побогаче — вам стоит обратить внимание на Kingdom Come: Deliverance. Чешская RPG про Богемию 14 века сильно вдохновлялась «Готикой» и построена на её геймдизайнерских идеях: хардкор, честное отношение к игроку, иммерсивные механики. Цитирование игр Piranha Bytes доходит до такой степени, что в сиквеле главный герой теряет все свои навыки из-за травмы, как и Безымянный в Gothic 2.

Не обошлось и без «нашего ответа» Gothic. СНГ-разработчики выпустили Of Ash and Steel — RPG в оригинальном сеттинге, которое предлагает свой взгляд на формулу «Готики» с добавлением массы новых идей вроде элементов survival-игр и осовремененной боевой системы. К слову, в русском дубляже на озвучке главного героя Пётр Гланц — теперь уже официальный голос Безымянного из «Готики» и актёр, что озвучивал его во второй части.

Пожалуй, лучшее, во что вы можете сыграть после прохождения оригинальной трилогии или как минимум Gothic 2 — это «Хроники Миртаны: Архолос». Самостоятельная игра от польских мододелов на движке второй части и лучшая «Готика» из существующих. Совершенно феноменальная работа по всем возможным характеристикам: дизайн мира и заданий, персонажи, сюжет, геймплей, музыка (ради которой фанаты даже сняли целую консерваторию с живым оркестром).

«Архолос» — это приквел событий Gothic 1, расширяющий лор вселенной и предлагающий фанатское развитие некоторых знакомых по оригинальным играм персонажей. Сюжет посвящен беженцам от войны с орками, братьям Марвину и Йорну. Пытаясь спастись от надвигающейся орды, они на последние средства переплывают на Архолос — торговый остров неподалёку от Миртаны, который по воле Робара пользуется некоторой автономией от остального королевства. Обычная попытка сбежать от войны и начать новую жизнь оборачивается для братьев впутыванием в целый клубок политических интриг, захватывающих все главные силы острова, само королевство и даже конфликт трёх богов мира «Готики».

Мод совершенно бесплатный для владельцев Gothic 2 в Steam. Он прекрасно работает, полностью переведён на русский язык (на озвучке как профессиональные актёры, так и некоторые блогеры из сообщества «Готики») и подарит вам до 100 часов невероятного RPG-опыта только за одно прохождение. Даже в отрыве от контекста Gothic «Архолос» — это одна из лучших ролевых игр на рынке, которую смело хочется ставить в один ряд с классикой вроде «Ведьмака» и всё той же Kingdom Come.

Если вы пропустили эту фанатскую работу или знали о ней, но долго откладывали — до конца 2026 года обещают масштабное обновление 2.0, которое расширит игру горой контента, переработкой некоторых систем, новыми заданиями и случайными встречами, а также приятными мелочами вроде опционального хардкор-режима, возможности менять внешность главному герою и мини-игр.

Важно: если вы решитесь пробовать «Архолос» — зайдите в .ini-файл игры и по примеру гайда для Gothic 2 включите себе быстрые сохранения и быстрое применение зелий. Баг со звуком около воды тут тоже присутствует (как-никак, один и тот же движок) и чинится тем же самым способом.