Привет! Спасибо за внимательный разбор — да, с платформой ошиблись, уже поправили: речь про ESC8000A-E13.
По расчётам вы правы, если рассматривать площадку как GPU-кластер. Но у нас ЦОД используется под разные сценарии (bare metal, облако, GPU-задачи, инфраструктурные сервисы) в зависимости от задач клиентов.
Поэтому нагрузка по стойкам сильно отличается: где-то это GPU-серверы, где-то — более лёгкая инфраструктура. В среднем по площадке получается именно такая цифра.
Плюс мы изначально закладываем запас под рост и новые размещения, а не заполняем всё впритык.
Так и есть — без Госуслуг не получится зарегистрировать домен в зоне .ru (а еще в .рф и .su). Существующие домены продлить без идентификации тоже не получится — когда регистрация домена закончится, он перейдет в режим ожидания продления, а потом освободится. На этой странице коллеги из Руцентра собрали самое важное, что нужно знать об идентификации.
Привет! Вот прямо сейчас вакансий на Perl у нас нет, но периодически они появляются — посматривать можно у нас на hh. А еще можно закинуть резюме в форму в нашей группе ВК — обменяемся контактами и будем на связи.
Здравствуйте, спасибо за комментарий и за мысль про «контент без редактора» — да, это действительно работает!
Цель текста не в том, чтобы сказать, что программисты не нужны или что всё можно заменить ИИ. Скорее наоборот — в процессе я как раз убедилась, что у каждого своя зона экспертизы, и когда люди занимаются своим делом, результат получается быстрее и качественнее. Но мне было важно попробовать собрать инструмент для себя, чтобы закрыть конкретную потребность. Получилось не идеально, но меня порадовал сам процесс. Хотелось поделиться этим опытом и, возможно, вдохновить кого-то ещё на эксперимент.
По техническому моменту: 0 я сознательно не считала «пустым» значением, поэтому не заменяла его на прочерк. Мне было проще разделить «нет данных» и «значение равно нулю». Сейчас, конечно, понимаю, что это можно было оформить аккуратнее.
Что касается пайплайна и клиент-серверного взаимодействия — в статье я показала только иллюстративный фрагмент, чтобы не растягивать и без того длинный текст. Насколько я могу судить, поток там довольно стандартный: route → Supabase → сбор данных → ответ фронту. Если будет интересно, могу рассказать подробнее!
Спасибо за комментарий и, видимо, идею к следующей статье (возможно, даже не одной)!
В статье мы разбирали кейс внесения изменений в конкретную систему с документацией. О том, как в принципе писать понятную документацию к текущим процессам, можно писать столько, сколько существует различных процессов:) Но если очень коротко формулировать, как это реализовать — одним UML точно не отделаешься, ещё понадобятся, минимум, грамотная структура и лёгкий понятный текст.
Отвечая на ваш вопрос о Прецедентах и Классах: во-первых, на диаграмме Прецедентов хорошо видно, когда появляются новые сценарии. С этой диаграммы начинается рисование комплекта диаграмм. Диаграмма Последовательности конкретизирует выявленные Прецеденты. В процессе рисования диаграммы Прецедентов можно сразу понять, какой сценарий лишний, и не тратить время на расписывание Последовательности. Во-вторых, многие разработчики мыслят объектами. Классы помогают приблизить архитектуру к разработке. По Классам видно, как Заказ или Услуга будут кочевать по разным модулям, и по каким атрибутам связываться.
На первый взгляд и вправду похоже на MFE! Но у нас не классический module federation/iframe-подход. Скорее это «виджетная модель» поверх одного хост-приложения. Соответственно, такие компоненты подключаются как независимые через ленивую загрузку: если виджет не фигурирует в конфигурации страницы, его код вообще не попадает в итоговый бандл. Границы отказа держим на уровне реализации виджетов: у каждого есть своё состояние, свои fallback’и.
За счёт единого билда и общего runtime мы избегаем типичных для module federation историй с размазыванием версий и shared-зависимостей. Гибкость и расширяемость достигаются за счёт конфигурации и контрактов между фронтом и бэкендом, а не за счёт набора разнесённых remote-бандлов. Т.е., по сути это контролируемая композиция и ленивое подключение компонентов на уровне виджетов, но не MFE в строгом, инфраструктурном смысле.
Ну и дисклеймер на всякий случай: такой подход не является «серебряной пулей» и подойдёт не всем, но в нашем случае выбранная модель хорошо покрывает текущие потребности по масштабированию, отказоустойчивости и управляемости, мы вполне осознаём её границы и возможные зоны роста.
Готовые решения могут быть выходом, но подойдут ли — зависит от ваших требований и задач. В нашем случае они всех наших требований не покрывали. Поэтому мы начали смотреть в сторону разработки собственной архитектуры на базе Next.js с выделенным BFF и рассчитывали, что такой подход
ускорит разработку,
позволит масштабировать команду без ограничений, распределяя разработчиков по отдельным виджетам.
Дока и у нас появляется в начале проекта, но на этом этапе ее пишут аналитики, архитекторы и разработчики. Уже потом появляются техписы и документируют всё в подробностях: со схемами, сценариями — и как раз ссылками на Swagger. Так коллеги смогут обратиться к этому документу, когда запланируют изменения в каких-то процессах. Можно было бы в самом начале прописать контракт и архитектуру, чтобы это стало актуальной документацией, но это все-таки не наш вариант — нам нужно расширять и структурировать проектную доку так, чтобы потом было легче понять бизнес-процесс и быстрее в нём сориентироваться, чтобы внести изменения.
Понятно, что у нас есть не только Swagger — документация логики взаимодействия сервисов между собой есть в виде текста, пользовательских сценариев, UML-диаграмм, на которых как раз обозначены методы. В некоторых случаях мы помечаем, что в конкретных ситуациях передается и что возвращается. Такая документация и Swagger дополняют друг друга.
Спасибо за совет! Мы подходили к процессу как к эксперименту — и в статье описывали его так же. Понимаем, что он требует доработки, раз решили придерживаться этого направления. Возможно, придем к чему-то похожему.
Привет, спасибо за комментарий! В нашем случае проблема была в том, что у разработчиков не хватало времени на доскональное описания параметров, методов, ошибок в Swagger. Статья больше про то, как мы совместными усилиями решали эту проблему.
Здравствуйте! Да, вы верно подметили, что в статье много упрощенных примеров. Сделано это намеренно, а одна из основных целей выбора такого стиля — слегка "подтолкнуть" к использованию k8s тех, кто могли бы его использовать, но пока не решаются🙂
Но в статье есть ряд мыслей и для опытных пользователей. Вот одна из них: k8s стал не просто стандартным инструментом для sysadmins/ops/devops/sre/platform/\…(aiops?), но и для разработки. Так, вчера любой разработчик умел поместить свой сервис в докер, а сегодня опытные разработчики с легкостью запустят свой сервис в k8s самостоятельно, поскольку умеют им пользоваться и знают принципы работы.
А это означает, что еще до написания кода все участники доставки ценности понимают, где сервис будет запущен, каким принципам должен соответствовать, каковы принципы межсервисного взаимодействия. Таким образом, общий контекст разработчиков/тестировщиков/админов — важная составляющая, которая существенно сокращает time-to-market.
Всё зависит от ваших целей. Если в них входит стабильная работа на годы вперёд — да, натягивать кубер будет одним из способов достичь такого результата.
Привет! Спасибо за внимательный разбор — да, с платформой ошиблись, уже поправили: речь про ESC8000A-E13.
По расчётам вы правы, если рассматривать площадку как GPU-кластер. Но у нас ЦОД используется под разные сценарии (bare metal, облако, GPU-задачи, инфраструктурные сервисы) в зависимости от задач клиентов.
Поэтому нагрузка по стойкам сильно отличается: где-то это GPU-серверы, где-то — более лёгкая инфраструктура. В среднем по площадке получается именно такая цифра.
Плюс мы изначально закладываем запас под рост и новые размещения, а не заполняем всё впритык.
Нет, требования распространяются только на домены второго уровня.
Так и есть — без Госуслуг не получится зарегистрировать домен в зоне .ru (а еще в .рф и .su). Существующие домены продлить без идентификации тоже не получится — когда регистрация домена закончится, он перейдет в режим ожидания продления, а потом освободится. На этой странице коллеги из Руцентра собрали самое важное, что нужно знать об идентификации.
Привет! Вот прямо сейчас вакансий на Perl у нас нет, но периодически они появляются — посматривать можно у нас на hh. А еще можно закинуть резюме в форму в нашей группе ВК — обменяемся контактами и будем на связи.
Здравствуйте, спасибо за комментарий и за мысль про «контент без редактора» — да, это действительно работает!
Цель текста не в том, чтобы сказать, что программисты не нужны или что всё можно заменить ИИ. Скорее наоборот — в процессе я как раз убедилась, что у каждого своя зона экспертизы, и когда люди занимаются своим делом, результат получается быстрее и качественнее. Но мне было важно попробовать собрать инструмент для себя, чтобы закрыть конкретную потребность. Получилось не идеально, но меня порадовал сам процесс. Хотелось поделиться этим опытом и, возможно, вдохновить кого-то ещё на эксперимент.
По техническому моменту:
0я сознательно не считала «пустым» значением, поэтому не заменяла его на прочерк. Мне было проще разделить «нет данных» и «значение равно нулю». Сейчас, конечно, понимаю, что это можно было оформить аккуратнее.Что касается пайплайна и клиент-серверного взаимодействия — в статье я показала только иллюстративный фрагмент, чтобы не растягивать и без того длинный текст. Насколько я могу судить, поток там довольно стандартный:
route → Supabase → сбор данных → ответ фронту. Если будет интересно, могу рассказать подробнее!Спасибо за комментарий и, видимо, идею к следующей статье (возможно, даже не одной)!
В статье мы разбирали кейс внесения изменений в конкретную систему с документацией. О том, как в принципе писать понятную документацию к текущим процессам, можно писать столько, сколько существует различных процессов:) Но если очень коротко формулировать, как это реализовать — одним UML точно не отделаешься, ещё понадобятся, минимум, грамотная структура и лёгкий понятный текст.
Отвечая на ваш вопрос о Прецедентах и Классах: во-первых, на диаграмме Прецедентов хорошо видно, когда появляются новые сценарии. С этой диаграммы начинается рисование комплекта диаграмм. Диаграмма Последовательности конкретизирует выявленные Прецеденты. В процессе рисования диаграммы Прецедентов можно сразу понять, какой сценарий лишний, и не тратить время на расписывание Последовательности. Во-вторых, многие разработчики мыслят объектами. Классы помогают приблизить архитектуру к разработке. По Классам видно, как Заказ или Услуга будут кочевать по разным модулям, и по каким атрибутам связываться.
Спасибо, поправили :)
На первый взгляд и вправду похоже на MFE! Но у нас не классический module federation/iframe-подход. Скорее это «виджетная модель» поверх одного хост-приложения. Соответственно, такие компоненты подключаются как независимые через ленивую загрузку: если виджет не фигурирует в конфигурации страницы, его код вообще не попадает в итоговый бандл. Границы отказа держим на уровне реализации виджетов: у каждого есть своё состояние, свои fallback’и.
За счёт единого билда и общего runtime мы избегаем типичных для module federation историй с размазыванием версий и shared-зависимостей. Гибкость и расширяемость достигаются за счёт конфигурации и контрактов между фронтом и бэкендом, а не за счёт набора разнесённых remote-бандлов. Т.е., по сути это контролируемая композиция и ленивое подключение компонентов на уровне виджетов, но не MFE в строгом, инфраструктурном смысле.
Ну и дисклеймер на всякий случай: такой подход не является «серебряной пулей» и подойдёт не всем, но в нашем случае выбранная модель хорошо покрывает текущие потребности по масштабированию, отказоустойчивости и управляемости, мы вполне осознаём её границы и возможные зоны роста.
Готовые решения могут быть выходом, но подойдут ли — зависит от ваших требований и задач. В нашем случае они всех наших требований не покрывали. Поэтому мы начали смотреть в сторону разработки собственной архитектуры на базе Next.js с выделенным BFF и рассчитывали, что такой подход
ускорит разработку,
позволит масштабировать команду без ограничений, распределяя разработчиков по отдельным виджетам.
Наши ожидания оправдались☺
Привет, спасибо за советы! Это мы изучим.
Привет, спасибо)
Дока и у нас появляется в начале проекта, но на этом этапе ее пишут аналитики, архитекторы и разработчики. Уже потом появляются техписы и документируют всё в подробностях: со схемами, сценариями — и как раз ссылками на Swagger. Так коллеги смогут обратиться к этому документу, когда запланируют изменения в каких-то процессах. Можно было бы в самом начале прописать контракт и архитектуру, чтобы это стало актуальной документацией, но это все-таки не наш вариант — нам нужно расширять и структурировать проектную доку так, чтобы потом было легче понять бизнес-процесс и быстрее в нём сориентироваться, чтобы внести изменения.
Понятно, что у нас есть не только Swagger — документация логики взаимодействия сервисов между собой есть в виде текста, пользовательских сценариев, UML-диаграмм, на которых как раз обозначены методы. В некоторых случаях мы помечаем, что в конкретных ситуациях передается и что возвращается. Такая документация и Swagger дополняют друг друга.
Смотря какой и смотря зачем — финал всё равно всегда проверяют разработчики перед коммитом.
Спасибо за совет! Мы подходили к процессу как к эксперименту — и в статье описывали его так же. Понимаем, что он требует доработки, раз решили придерживаться этого направления. Возможно, придем к чему-то похожему.
Привет, спасибо за комментарий! В нашем случае проблема была в том, что у разработчиков не хватало времени на доскональное описания параметров, методов, ошибок в Swagger. Статья больше про то, как мы совместными усилиями решали эту проблему.
Привет! Добавили расшифровку в самое начало, но если вы ощущаете себя станцией технического обслуживания, мы принимаем ваш выбор.
В нашем случае акцент был сделан на простоте и готовности решения — Ollama уже использовалась в другом нашем недавнем продукте с ИИ-ассистентом.
Здравствуйте! Да, вы верно подметили, что в статье много упрощенных примеров. Сделано это намеренно, а одна из основных целей выбора такого стиля — слегка "подтолкнуть" к использованию k8s тех, кто могли бы его использовать, но пока не решаются🙂
Но в статье есть ряд мыслей и для опытных пользователей. Вот одна из них: k8s стал не просто стандартным инструментом для sysadmins/ops/devops/sre/platform/\…(aiops?), но и для разработки. Так, вчера любой разработчик умел поместить свой сервис в докер, а сегодня опытные разработчики с легкостью запустят свой сервис в k8s самостоятельно, поскольку умеют им пользоваться и знают принципы работы.
А это означает, что еще до написания кода все участники доставки ценности понимают, где сервис будет запущен, каким принципам должен соответствовать, каковы принципы межсервисного взаимодействия. Таким образом, общий контекст разработчиков/тестировщиков/админов — важная составляющая, которая существенно сокращает time-to-market.
Можно ли ответить популярной гифкой?
Например, для того, чтобы собрать инфраструктуру из 10 инстансов.
Всё зависит от ваших целей. Если в них входит стабильная работа на годы вперёд — да, натягивать кубер будет одним из способов достичь такого результата.