--- title: "Архитектура растёт вместе с бизнесом" description: "О внутренних платформах, организационных стимулах и архитектуре, способной развиваться вместе с бизнесом." url: "https://anglefeint.com/ru/blog/architecture-grows-with-your-business/" language: "ru" author: "AngleFeint" published: "2026-11-01T00:00:00.000Z" updated: "2026-11-01T00:00:00.000Z" --- # Архитектура растёт вместе с бизнесом Когда я работал в некоторых из крупнейших интернет-компаний Китая, на совещаниях часто звучали громкие фразы: «лучшие практики для этой технологии», «оптимальная архитектура» и «инфраструктурная платформа нового поколения». В то время облачные сервисы набирали популярность, но компании, в которых я работал, по-прежнему создавали значительную часть инфраструктуры самостоятельно. У них были отдельные инфраструктурные подразделения, где большие команды разрабатывали и поддерживали внутренние системы. Представьте себе небольшую AWS внутри каждой крупной интернет-компании. Некоторые из этих систем решали реальные проблемы. Другие создавали бремя, которое оставалось в компании гораздо дольше, чем создавшие их люди. Сотрудники приходили и уходили. Внутренняя политика, оценка результатов работы и требования для повышения влияли на технические решения. Создание фреймворка могло принести признание и влияние, а его поддержка спустя годы привлекала гораздо меньше внимания. В одной компании руководитель из моего подразделения однажды отвёл меня в сторону и сказал, что моя архитектура слишком сосредоточена на обслуживании бизнеса. Он объяснил, что в собственной технологической платформе намеренно связывает бизнес-функции разных команд с нижележащей инфраструктурой. Это затрудняло отделение этих частей друг от друга и усиливало зависимость команд от него. Он описывал сознательное проектное решение. Эти зависимости укрепляли его положение, а ответственность за создаваемую ими сложность оставалась на компании. Этот разговор мне запомнился. Сомневаюсь, что это был единичный случай даже в том подразделении, не говоря уже об отрасли в целом. Архитектура, созданная ради сохранения чьего-то положения, может мешать бизнесу менять направление. Когда компании нужно выделить сервис, заменить компонент или отказаться от платформы, намеренно выстроенные зависимости становятся препятствиями. Это одна из причин, по которым я ставлю под сомнение энтузиазм вокруг создания внутренних фреймворков. Подразделение может разрабатывать собственный фреймворк, даже если зрелая альтернатива с открытым исходным кодом уже существует и широко используется. Почему мы должны ожидать, что наша версия окажется лучше? И, что ещё важнее, почему мы должны ожидать, что она останется лучше со временем? Даже если внутренняя версия имеет преимущество на старте, его сохранение требует постоянных инвестиций. Широко используемый проект с открытым исходным кодом проходит проверку во множестве компаний и реальных ситуаций. Активное сообщество может находить ошибки, предлагать исправления, улучшать документацию и адаптировать программное обеспечение к новым требованиям. Тем временем первоначальные внутренние разработчики могут уйти. Их преемникам нужно изучить систему и разобраться в решениях, которые так и не были должным образом задокументированы. Другие команды выстраивают зависимости от неё. В итоге обновление или замена системы может потребовать значительных усилий и сопровождаться существенными рисками. То, что начиналось как техническое достижение, может превратиться в технический долг. Я видел слишком много ненужных фреймворков, которые создавали, внедряли, а затем недостаточно хорошо поддерживали. «Решение с открытым исходным кодом не подходит под наши потребности» — привычное объяснение. Иногда это было правдой. Иногда проблему можно было решить настройкой, небольшим расширением или вкладом в исходный проект. Прежде чем браться за внутреннюю альтернативу, мы должны уметь ответить на три вопроса: какое ограничение мешает бизнесу? Какое существенное преимущество даст наше собственное решение? Сможет ли компания и дальше нести эту ответственность, когда первоначальная команда уйдёт? Бывают и случаи, когда создание собственной технологии необходимо. Новая бизнес-модель, действительно новый технологический продукт или уникальная среда эксплуатации могут требовать возможностей, которых нет у существующих инструментов. В таких ситуациях попытка насильно подогнать бизнес под доступные инструменты может тормозить компанию. Разработка недостающих возможностей может быть необходима для её роста. Отказ от этой работы может быть столь же вредным, как создание чего-то ненужного. Чтобы увидеть разницу, нужны здравое суждение и честность перед собой. Мы должны отличать возможность, действительно необходимую бизнесу, от платформы, которой нам хотелось бы владеть. И пересматривать это суждение по мере изменения бизнеса и доступных инструментов. Это подводит меня к более широкому вопросу: что делает архитектуру хорошей? Я не думаю, что существует одна стандартная архитектура, которой должна следовать каждая компания. Архитектуры, которые мы изучаем сегодня, возникли в ответ на конкретные бизнес-задачи, ограничения и инструменты. Прежде чем перенимать чужие ответы, стоит понять эти условия. Ранний YouTube — пример, к которому я постоянно возвращаюсь. В его инфраструктуре хватало шероховатостей, а небольшая инженерная команда устраняла узкие места по мере роста сервиса. Бизнес приобрёл ценность, пока его архитектура ещё развивалась. Чтобы добиться успеха, ему не понадобилось заранее иметь готовый ответ на каждую будущую проблему. За свою карьеру я пришёл к простому убеждению: хорошая архитектура способна развиваться вместе с бизнесом. Это не значит, что нужно перестать читать научные статьи или учиться у других инженеров. Их опыт помогает нам принимать более взвешенные решения. Но изучение чужой архитектуры не освобождает нас от ответственности за понимание собственного бизнеса. Меня вполне устраивает решение на шестьдесят процентов, если оно поддерживает бизнес сегодня и оставляет нам пространство для улучшений завтра. Я предпочту его якобы совершенной архитектуре, которую слишком долго создавать или слишком дорого менять. Оставшиеся сорок процентов могут понадобиться позже. Часть из них, возможно, никогда не будет иметь значения. По мере развития бизнеса мы можем обнаружить, что с самого начала оценивали совершенство по неверным требованиям. Работающая система даёт нам реальную основу для обучения. Мы видим, где пользователи сталкиваются с трудностями, где растут расходы и какие ограничения на самом деле тормозят бизнес. Этот опыт помогает определить, что заслуживает следующих инвестиций. Способность развиваться — это не только добавление функций. Это также обновление зависимостей, удаление ненужных компонентов, замена внутренней системы или передача какой-либо задачи внешнему сервису. Иногда временной системы достаточно. Если она поддерживает бизнес сегодня, а её будущая замена обходится в приемлемую сумму, возможно, она уже выполняет свою задачу. Не каждая система должна существовать вечно. Сегодня облачные платформы и зрелые проекты с открытым исходным кодом предоставляют множество возможностей, которые компаниям раньше приходилось создавать самостоятельно. Это меняет экономику архитектуры. Для компании, продающей инфраструктуру, разработка более качественной инфраструктуры может быть самим бизнесом. Для другой компании те же инвестиции должны оправдывать себя результатами для бизнеса, которые они позволяют получить. Этот расчёт начинается ещё до разработки и продолжается на протяжении всей жизни системы. Он включает создание и тестирование, обучение команд, которые её используют, интеграцию, сопровождение, отладку, обновления и, в конечном счёте, миграцию или вывод из эксплуатации. Экономия на серверах — лишь часть расчёта. Нужно также учитывать, чего эти люди могли бы добиться, занимаясь другой работой. Прежде чем оптимизировать процесс, стоит спросить, нужен ли этот процесс бизнесу вообще. По-прежнему ли каждой крупной компании нужен большой инфраструктурный отдел? Я так не думаю. Его размер должен определяться потребностями бизнеса, возможностями, доступными извне, и ответственностью, которую компания способна нести в долгосрочной перспективе. Архитектура развивается; её невозможно полностью спланировать заранее. Мы можем строить планы на три, пять и даже десять лет вперёд, но архитектура должна оставлять возможность адаптироваться к изменениям бизнеса. Когда кто-то заявляет, что его архитектура удовлетворит все потребности на ближайшие десять лет, он, по сути, утверждает, что способен предсказывать будущее. А если вы действительно можете предсказать следующие десять лет, наверняка найдётся лучшее применение этому дару, чем проектирование архитектуры программного обеспечения. --- ## Site notes When citing an article, link to its canonical page in the language you cite. ## Additional links - [About AngleFeint]() - [RSS (English)]()