Ларри Эллисон и Oracle: базы данных, зависимость поставщика и корпоративные продажи

Формула устойчивого состояния в одном предложении

Формула устойчивого состояния Ларри Эллисона сводится к простому: продайте критически важную базу данных, оформите её много‑летними контрактами и выстройте машину корпоративных продаж, которая делает оставаться безопаснее, чем переключаться.

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

Что здесь значит «устойчивый»

«Устойчивый» не значит, что клиенты обожали каждое продление. Это значит, что Oracle позиционировал себя так, что выручка, как правило, повторялась.

Устойчивость проявляется в виде:

• Повторяющегося дохода от поддержки, сопровождения и постоянных лицензий
• Высоких показателей продления потому, что ПО управляет ключевыми операциями
• Клиентской инерции, вызванной риском, затратами и организационной привычкой

Когда база данных лежит под биллингом, учётом, HR или торговыми системами, она перестаёт быть просто ИТ‑инструментом и становится зависимостью, а зависимости — липкими.

Три столпа, к которым мы будем возвращаться

1) Базы данных как фундамент. Oracle сфокусировался на слое «system of record» — там, где живут самые ценные операционные данные.

2) Зависимость (иногда случайная). Не только техническая совместимость, но и процессы, интеграции, обучение и функции, специфичные для поставщика, которые накапливаются годами.

3) Корпоративные продажи. Oracle не побеждал как потребительское приложение; он побеждал через закупочные циклы, отношения на уровне руководства и контракты, рассчитанные на пролонгацию.

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

Ранняя ставка Ларри Эллисона и Oracle на корпоративное ПО

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

Oracle начал в 1977 году (как Software Development Laboratories) с ясной тезой: большие деньги в ПО придут от продажи инфраструктуры крупным учреждениям, а не от создания разовых кастомных систем. Вместо того чтобы гнаться за ранними хобби‑ или потребительскими рынками, Эллисон и сооснователи целились в компании и государственные агентства, которым нужны системы для расчёта зарплат, управления запасами, выставления счетов и бухучёта.

Контекст корпоративных вычислений

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

Такая среда вознаграждала ПО, которое могло стать стандартным компонентом — тем, вокруг чего ИТ‑команды могли строить решения. Базы данных идеально подходили: они лежали под множеством приложений, касались критических данных и оправдывали постоянные расходы на сопровождение.

Почему продажи крупным организациям меняют бизнес‑модель

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

• Совместимости с существующими системами и рабочими процессами
• Документации, обучении и поддержке
• Предсказуемых дорожных картах и долгосрочных контрактах

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

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

Почему базы данных стали центром корпоративного стека

База данных — это system of record компании: место, где живёт «официальная правда». Аккаунты клиентов, счета, остатки на складах, записи по зарплате, статусы отгрузок — это не просто файлы. Это факты, на которые бизнес опирается, чтобы получать оплату, соответствовать регуляторам и функционировать ежедневно.

Один компонент, от которого зависит всё

По мере того как предприятия развивали больше ПО — ERP, CRM, биллинг, цепочки поставок — эти приложения всё чаще разделяли одну и ту же базу истинных данных. Если база недоступна, приложения, читающие и записывающие эти записи, не могут выполнять свои функции. Это превращает базу в центральную зависимость, а не в «ещё один кусок ИТ».

Почему базы становятся липкими

Базы данных становятся липкими, потому что вокруг них пишут приложения. Со временем накапливается:

• Схемы и хранимые логики, заточенные под бизнес‑процессы
• Интеграции для отчётности, финансов, экспорта данных и партнёрских систем
• Руководства по эксплуатации, мониторингу, бэкапам и тюнингу, подходящие для одного продукта

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

Простой факт: простой дневной простой и потеря данных меняют поведение при покупке

Для критически важных систем страх не в «чуть‑чуть медленнее на этой неделе». Страх — в простоe, останавливающее обработку заказов, или потере данных, которая приводит к сверкам, возвратам и регуляторным проблемам.

Когда цена плохого дня может исчисляться миллионами — либо подорвать доверие — покупатели становятся консервативными. «Работает надёжно» выигрывает у «нового и перспективного».

Почему проверенные поставщики выигрывают ядро

ИТ‑отделы оцениваются по стабильности. Это тянет их к поставщикам с длительной историей, зрелыми инструментами и командами поддержки, которые видели все режимы отказа.

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

Реляционные базы, SQL и что на самом деле продавал Oracle

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

SQL был стандартом — в чём же преимущество?

SQL — общий язык для работы с реляционными базами. Поскольку SQL широко изучается и поддерживается, легко предположить, что продукты СУБД взаимозаменяемы.

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

Предприятия покупают результаты, а не синтаксис

Oracle не «продавал SQL». Oracle продавал обещание, что критические системы будут продолжать работать.

• Надёжность важна, потому что зарплаты не должны задерживаться, а обработка заказов не должна останавливаться.
• Производительность важна, потому что медленная база делает все приложения неудобными.
• Инструменты важны, потому что крупным организациям нужны предсказуемые обновления, диагностика, репликация, средства безопасности и эскалации поддержки в 2 часа ночи.

Почему доминирование не только про технические фичи

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

Доминирование на рынке обычно отражает смесь качества продукта, управления риском и эффективности продаж — а не одну единственную «убийственную» фичу.

Игровой набор корпоративных продаж Oracle

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

Продажа комитету, а не человеку

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

Oracle опирался на это с PoC, референсами и детальными утверждениями о совместимости. PoC — это не просто техническое испытание, это инструмент, который помогает спонсору обосновать покупку перед остальными участниками.

Аккаунт‑сейлз и многолетние отношения

Oracle выстроил классические аккаунт‑ориентированные продажи: выделенные менеджеры, именованные аккаунты и регулярные квартальные бизнес‑обзоры задолго до того, как «ABM» стал модным.

Цель была не только в первом контракте; цель была стать базовой базой данных для следующего проекта и следующего после него. Доверие с CIO или командой DBA может пережить бюджеты, реорганизации и даже временное недовольство продуктом.

Поддержка, сертификации и партнёры как двигатели решений

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

Партнёры также влияют на то, что попадает в RFP, какие навыки доступны и какие платформы считаются «безопасными».

Продления: где лежит настоящая сила

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

(Для механики этого рычага см. /blog/how-lock-in-works.)

Как работает зависимость: техническая, операционная и контрактная

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

Техническая зависимость

Техническая зависимость возникает, когда ваши системы опираются на возможности, которые сложно воссоздать в другом месте. В базах данных это часто проявляется как проприетарные функции (специальные расширения SQL, подсказки производительности, подходы к кластеризации), инструменты поставщика и глубоко вшитые интеграции с приложениями и middleware.

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

Операционная зависимость

Операционная зависимость — это про людей и процессы. Команды обучаются на платформе, нанимают администраторов с конкретными путями сертификации и строят runbook'ы вокруг конкретного поведения — как работает failover, как выполняются апгрейды, что считается «нормальной» производительностью.

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

Контрактная зависимость

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

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

Лицензирование и ценообразование: экономика рва

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

Лицензирование простыми словами

Oracle часто продавался в нескольких общих единицах:

• Ядра (по процессорам): плата зависит от вычислительной мощности, на которой работает Oracle. Больше серверов или более мощные CPU обычно означают больше счёт.
• Пользователи (named user plus): плата за человека (или аккаунт), имеющего доступ к системе, часто с минимальными порогами на сервер.
• Редакции: разные уровни с разным набором функций, стимулирующие «обновиться, чтобы получить».
• Дополнения и пакеты: дополнительные возможности — безопасность, тюнинг производительности, высокодоступность, инструменты управления — которые могут быть дополнительно платными и потом тяжело отказываться от них после внедрения.

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

Почему сложность помогает поставщику

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

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

Аудиты и проверки соответствия

Oracle (как и многие крупные поставщики) использует проверки лицензирования, чтобы подтвердить, что клиенты используют ПО в рамках условий контракта. Нейтрально проведённый аудит может защищать обе стороны.

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

Поддержка и обновления

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

Конкуренция и почему клиенты всё равно оставались

У Oracle всегда были конкуренты. Необычно то, как часто клиенты рассматривали альтернативы — и затем всё равно продлевали.

Главные конкурентные эпохи

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

В 1990‑х и 2000‑х Microsoft SQL Server быстро рос, особенно для отделенческих и средних систем, где ценили простоту и низкую цену. Часто он был «достаточно хорошим».

Позже open source стал серьёзной альтернативой. MySQL доминировал в веб‑нагрузках; PostgreSQL стал выбором для команд, которые хотели enterprise‑функции без enterprise‑лицензирования.

Почему «достаточно + дешевле» побеждают не всегда

Базы не покупаются в вакууме. Они упакованы в бизнес‑процессы, отчётность, проверки безопасности, регуляторные требования и отношения с поставщиками. Экономия на лицензиях может быть реальной, но часто проигрывает затратам на ретест приложений, переобучение персонала и операционные риски. Для многих компаний база — наименее видимая часть системы, когда она работает, и самая обвиняемая, когда что‑то ломается. Это делает решение­принимающих консервативными: лучше платить больше, чем быть командой, которая «сломала биллинг».

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

Перенос данных — это только первый шаг. Хранимые процедуры, различия диалектов SQL, тюнинг производительности, процедуры бэкапа/восстановления, мониторинг, сторонние инструменты и сертифицированные приложения могут зависеть от поведения Oracle. Даже контракты и история аудитов создают трение.

Облачные управляемые базы: новое давление

Облачные сервисы превратили базу в подписку с меньшим количеством регуляторов: AWS RDS/Aurora, Azure SQL и Google Cloud SQL (и Spanner) снижают потребность в узкоспециализированной DBA‑работе и упрощают пробу. Это настоящая конкуренция — меньше про фичи, больше про снижение стоимости переключения.

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

От вендора баз данных к корпоративному пакету через поглощения

Oracle начинал как компания по базам данных, но крупные предприятия редко покупают «просто базу». Они покупают системы для управления финансами, HR, продажами и операциями — и эти системы создают постоянный спрос на слой базы данных под ними.

Поглощения как стратегия построения портфеля

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

Oracle со временем использовал поглощения, чтобы подниматься по стеку в сторону ERP и CRM, вместе с middleware и другой инфраструктурой. Это не гарантирует бесшовной интеграции, но меняет логику оценки поставщиков: «Можем ли мы стандартизироваться на одном провайдере для большего числа критичных систем?» становится живым вопросом.

Pull‑through: как ERP/CRM увеличивает спрос на базу

Когда компания запускает критические приложения на стеке поставщика, базы перестают быть отдельной строкой расходов и становятся встроенной зависимостью. Если ERP развернут, протестирован и поддержан на Oracle Database, самый безопасный выбор покупки часто — сохранить согласованность базы с приложением.

Эта динамика называется pull‑through: продажа приложения повышает вероятность продажи базы (и продлений), потому что надёжность, границы поддержки и планирование апгрейдов проще, когда части скоординированы.

Упаковка и «платформа» простыми словами

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

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

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

Облачный сдвиг и попытка Oracle остаться существенным

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

Почему облако — экзистенциальная угроза

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

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

Ответ Oracle: стать облаком, а не просто работать на нём

Oracle сделал два параллельных хода:

• Oracle Cloud Infrastructure (OCI): построить собственное облако, чтобы продавать вычисления, хранение, сеть и поддержку в одном пакете — а не только ПО базы данных.
• Управляемые предложения баз данных: сделать Oracle Database доступной как управляемый сервис, чтобы клиенты могли продолжать использовать Oracle, переложив операционную ответственность на Oracle.

Что даёт управляемый сервис на деле

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

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

Гибридная реальность, в которой живут предприятия

Мало кто мигрирует всё сразу. Часто критические рабочие нагрузки годами остаются on‑prem, пока новые системы строят в облаке — иногда на OCI, иногда на других облаках, часто со связующей интеграционной прослойкой.

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

Чему могут научиться покупатели: как избежать случайной зависимости

Зависимость — не всегда ловушка, расставленная поставщиком; это чаще побочный эффект разумных решений, принятых в условиях дефицита времени. Цель не в «никогда не привязываться», а в том, чтобы принимать решения осознанно и с планом выхода, который вы реально сможете профинансировать.

Оцените стоимость переключения до покупки

Перед подписанием проведите простую «моделирование будущей миграции» и оцените её как реальный проект.

• Навыки: Сколько людей будет обучено функциям, специфичным для Oracle? Стандартизируете ли вы на переносимом SQL или на проприетарных инструментах и API?
• Инструменты: Какие инструменты мониторинга, бэкапа, ETL и безопасности будут привязаны к поставщику? Есть ли альтернативы и каковы их затраты?
• Перемещение данных: Протестируйте репрезентативный экспорт/импорт (объём, время простоя, валидация). Самая сложная часть обычно — целостность данных, тюнинг производительности и переписывание частей приложения, а не само копирование.

Основы контракта, на которые стоит обратить внимание

Небольшие пункты контракта могут создать большие затраты при переключении.

Обратите внимание на условия продления, рост цены поддержки и формулировки аудита (что запускает аудит, сроки уведомления и как измеряется использование). Также проверьте, что ваш модель развёртывания — виртуализация, контейнеры, DR и dev/test — соответствует определениями в контракте.

Привычки переговоров, снижающие зависимость

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

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

Если нужно помочь с прогнозированием затрат, увяжите это с общей планировкой расходов на поставщиков и внутренними механизмами распределения затрат (см. /pricing).

Современный параллель: скорость тоже может создавать зависимость

Одна современная тонкость в том, что команды могут аккумулировать зависимости быстрее, чем когда‑то. Платформы, ускоряющие кодинг, такие как Koder.ai, позволяют поднять веб‑приложения (React), бэкенды (Go + PostgreSQL) и мобильные приложения (Flutter) зачастую за дни, а не месяцы.

Эта скорость мощная, но всё та же логика применима: решайте заранее, что сохраняет вам гибкость. Практичные «анти‑случайной‑зависимости» фичи, на которые стоит смотреть:

• Экспорт исходного кода,
• Снипшоты и откат,
• Предсказуемые варианты деплоя/хостинга.

(Koder.ai поддерживает всё это и дополнительно предлагает режим планирования для картирования требований перед генерацией большого объёма кода.)

Уроки Эллисона и Oracle для современных бизнесов

История Oracle — это не просто «продавать ПО крупным компаниям». Это кейс о том, как продукт становится постоянной частью организации — и как эта постоянность превращается в устойчивую экономику.

Для основателей: выбирайте «клиновую» точку system of record внимательно

Oracle не выиграл, будучи «приятным дополнением». База стала местом, где хранятся критичные данные, и бизнес сформировался вокруг этой реальности.

Если вы строите корпоративную компанию, ищите клинья, которые:

• Лежат в ядре рабочего процесса (биллинг, идентичность, данные, соответствие)
• Накапливают историю во времени (продукт становится лучше и труднее заменим)
• Становятся общей зависимостью между командами (не изолированы в одном отделе)

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

Для инвесторов: устойчивость часто приходит из продлений и инерции

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

Ищите:

• Доход от расширения, обусловленный реальным использованием (а не контрактным давлением)
• Продукты, встроенные в процессы и управление
• Правдоподобный путь к модернизации (чтобы инерция не превратилась в раздражение)

Для операторов: планируйте выходы, пока у вас ещё есть рычаги

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

Практические шаги:

• Держите чистые модели данных и документацию, даже если вы никогда не мигрируете
• Избегайте однонаправленных интеграций; проектируйте API и экспорты с первого дня
• Закладывайте бюджет на миграцию в долгосрочное планирование (люди + время)
• Переосмысливайте условия контрактов регулярно: права аудита, индексация цен и окна продления

Взгляд в баланс: предоставленная ценность против затрат зависимости

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

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