В Ria.ru поменяли Oracle на PostgreSQL

Развитие событий: Госструктуры откажутся от Oracle в пользу PostgreSQL (10 августа 2016)

По информации Roem.ru, "Россия сегодня" (в эту медиагруппу входят Ria.ru, "Прайм", ИноСМИ и другие проекты. Russia Today в группу не входит) прекратили использование продуктов Oracle. Все необходимые техпроцессы теперь завязаны на PostgreSQL, сопровождение которой обходится "на порядок дешевле".

Миграцией вторую половину 2015-го года занимались бывшие сотрудники Rambler Михаил Чеканов (Михаил ещё известен руководством веб-проектов Олимпийских игр в Сочи) и Сергей Томулевич. По словам Михаила Чеканова, получившаяся инфраструктура на базе PostgreSQL обходится "на порядок дешевле", подрядчики в ходе переезда не привлекались, внутри проекта использовали имеющиеся ресурсы: переводили часть проектов на PostgreSQL, освобождали оборудование, после чего переводили следующую часть.

По мнению Михаила Чеканова, парадоксом Oracle является то, что их главное конкурентное преимущество на рынке – это цена (которая, естественно, выше, чем у вариантов внедрения на PostgreSQL). Как объясняет Михаил Чеканов, в процессе выбора решения для инфраструктуры, лица принимающие решение могут обосновать выбор Oracle как "самое лучшее на рынке решение" и его "лучшесть" очевидна и понятна начальству из-за цены. Любое другое решение в случае каких-либо проблем даёт CTO возможность сказать, что начальство само виновато, поскольку не последовало рекомендациям технарей.

Использование Oracle, тем не менее, не гарантирует работоспособности даже критических приложений: например, в 2012-м году "Сбербанк" пережил падение процессинга своих карт, которое продолжалось вечером пятницы в течение трёх часов.

Как Oracle появился в "РИА Новостях"

На Oracle проекты МИА "Россия сегодня" (тогда ещё РИА "Новости") перешли в 2008-м году с той же PostgreSQL. Анатолий Стояновский, отвечавший за переезд в 2008-м, в комментарии Roem.ru так описал процесс и причины перевода:

Oracle использовался прежде всего для хранения особо критичных данных - в случае РИА это был новостной контент. У нас сложилась такая конфигурация - под базы данных Oracle были отданы лучшие сервера, лучшая команда DBA и системных администраторов. За почти 9 лет я не помню ни одной существенной аварии с потерей данных, и только несколько, приведших к короткой недоступности. Дальше это уже напоминает снежный ком: новые проекты автоматически строятся на Oracle. Эта СУБД обладает таким инструментарием анализа и оптимизации запросов, позволяет настолько детально препарировать их исполнение под высокой нагрузкой, что достаточно быстро это стало определяющим фактором в быстрой разработке.

Если говорить о нашей веб-платформе, то вопрос о переезде на более дешевые альтернативы поднимался почти каждый год. Мы безусловно имели возможность в любой момент начать перенос собственного ПО на другое хранилище данных. Но каждый раз баланс между рисками пусть временного, но снижения надежности и темпами развития склонялся в сторону последнего. Что означает проект переезда в ситуации динамично развивающейся компании? Команда разработчиков перестает заниматься новыми проектами на год (в нашем случае, т.к. ораклового кода было много). Мало перенести код, нужно его заново оптимизировать. Используя Oracle, мы потратили много времени на оптимальную балансировку производительности всех запросов, индексов, конфигураций и тп - в больших базах данных с динамическими (разными) запросами и высокой нагрузкой это очень важно. Немаловажный фактор - переобучение или замена системных администраторов. Не каждый сертифицированный Oracle DBA с таким же энтузиазмом переключится другие СУБД.

Первым этапом (еще в 2008 году) мы перенесли из Oracle в Postgres все данные, связанные с кэшированием, так что теперь мы могли горизонтально масштабироваться без приобретения дополнительных лицензий. Вторым этапом начался перенос некритичных к потере данных в другие хранилища (в основном это был MongoDB) - контент остался в Oracle, а такие вещи, как данные о пользователях и их поведении переехали в более удобные для таких задач хранилища. Третьим этапом был осуществлен перенос контента и полный отказ от Oracle (эту часть команда делала уже без меня - после ликвидации РИА Новости у программистов появилась возможность нормально сфокусироваться на этом проекте). Насколько я знаю, качеством работы под Postgres сейчас довольны.

Резюмируя, изначально Oracle был выбран по классической стратегии «не плодить зоопарк» - часть систем уже использовали эту СУДБ с каких-то древних лет, одно цеплялось за другое. Каждая новая команда сначала смотрела на Oracle с опаской, но спустя какое-то время признавала удобство работы. В условиях динамичного развития, оказалось дешевле оплачивать лицензии, чем связывать ресурсы команды переносом кода, хотя технологическая возможность этого в будущем закладывалась изначально. И далее - «мягкий» многоэтапный переезд на бесплатные аналоги с аккуратным планированием ресурсов.

Кто отходит от Oracle

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

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

"Мы реализуем стратегию перехода с дорогостоящих решений на СПО, в частности постепенно отказываемся от Oracle в пользу свободно распространяемых баз данных, таких как PostgreSQL и Tibero. Пока рассматриваем и осуществляем миграцию не критических для бизнеса систем, предварительно проводя оценку эффективности и трудоемкости миграции. Уже наращиваем внутреннюю компетенцию по сопровождению этих баз данных. В разработке новых систем дистанционного банковского обслуживания изначально закладываемся в сторону свободно распространяемых технологий и баз данных" — говорит Дмитрий Федоров, директор по развитию интернет технологий, ПАО "Ханты-Мансийский Банк Открытие"

Олег Бартунов, CEO Postgres Professional, по сути уже отвечал на претензии Oracle в отношении PostgreSQL, в частности, он отмечал, что проблем с производительностью PostgreSQL систем не выявляли крупные заказчики вроде пенсионного фонда Франции.


Объявление: в ближайшее время на Roem.ru планируется выпуск спецпроекта "Импортозамещение", по вопросам спонсорства обращайтесь в коммерческий отдел по адресу 5@roem.ru

Лучшие комментарии

  • Контекст комментария

    Mikhail Chekanov

    > Вообще-то основатель Oracle, Lawrence Joseph Ellison, бывший офицер ЦРУ,

    Кстати, ему приписывают громкую цитату: «если Oracle что-то и будет поставлять в Советский Союз, то это будут ракеты с ядерными боеголовками», но в отличие от бриновской «Нигерии в снегу» первоисточник недоступен.

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

  • Контекст комментария

    Bob Milner

    > Вообще-то основатель Oracle, Lawrence Joseph Ellison, бывший офицер ЦРУ,

    Ларри никогда не работал в ЦРУ, он работал в компании Амдал, которая в 77 году делала для ЦРУ секретный проект Oracle. Название этого проекта использовали затем для новой реляционной базы данных, которую тоже продали ЦРУ.

    Первым шутку про ракеты и Oracle начал распространять Марьянович, что не помешало им в начале 90х выбрать между СССР и Китаем СССР в качестве стратегического направления развития. Это, конечно, было ошибкой :)

Добавить 111 комментарий

  • Ответить

    Вообще-то основатель Oracle, Lawrence Joseph Ellison,,бывший офицер ЦРУ,где
    «бывших»,как все знают,не бывает.Долго же думали ,болезные,прежде чем сменить СУБД.

  • Ответить

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

  • Ответить
    Владимир Мяу и компания

    Я так-то без подвоха, тоже мечтаю на что-нибудь бесплатное соскочить с MS SQL. Пробовал мускл и SQLite, не взлетело, какие-то грустные поделки… Так что опыт масштабного слезания с Оракла очень интересен, надо будет покопать про них.

  • Ответить

    Еще в 2012 году для «РИА Новости» пилили внутренние сервисы на postgres, они наверное до сих пор живы. Еще тогда уже были у них громадные планы по отказу от оракла, но планы очень быстро умерли вместе с самими РИА :(

  • Ответить

    > sqlite вообще практически не поддерживает
    > многопользовательский режим

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

    > mssql работает с одним пользователем

    В смысле, принудительный монопольный режим, или что? Монопольный режим там есть, для всяких аварийных сценариев. Да проще сказать, чего там нет… Тем-то он и ценен, что просто берешь и используешь…

  • Ответить

    > > SQLite
    >
    > Это была шутка, да? Как можно пробовать sqlite
    > как замену настоящей бд?

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

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

  • Ответить

    Что-то автор напутал. Не было никакого перехода с PostgreSQL на Oracle в 2008. Наоборот в 2008 вынесли часть данных связанных с кешем в PostgreSQL из Oracle, что упомянуто в самой статье.

  • Ответить

    > Вообще-то основатель Oracle, Lawrence Joseph Ellison, бывший офицер ЦРУ,

    Кстати, ему приписывают громкую цитату: «если Oracle что-то и будет поставлять в Советский Союз, то это будут ракеты с ядерными боеголовками», но в отличие от бриновской «Нигерии в снегу» первоисточник недоступен.

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

  • Ответить
    Владимир Мяу и компания

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

  • Ответить

    > Вообще-то основатель Oracle, Lawrence Joseph Ellison, бывший офицер ЦРУ,

    Ларри никогда не работал в ЦРУ, он работал в компании Амдал, которая в 77 году делала для ЦРУ секретный проект Oracle. Название этого проекта использовали затем для новой реляционной базы данных, которую тоже продали ЦРУ.

    Первым шутку про ракеты и Oracle начал распространять Марьянович, что не помешало им в начале 90х выбрать между СССР и Китаем СССР в качестве стратегического направления развития. Это, конечно, было ошибкой :)

  • Ответить

    >SQLite

    Это отличная _встраиваемая_ бд. У нее своя ниша — внутри приложений, когда нужен хороший движок работы с данными. Пытаться делать из нее замену MSSQL/MySQL/Postgres — показатель полного непонимания, для чего вообще какой инструмент предназначен.

    >она поддерживает многопользовательский доступ к файлу

    Она даже чтение конкурентное не поддерживает. Что-то явно не то с документацией этой ;)

  • Ответить

    > показатель полного непонимания, для чего вообще
    > какой инструмент предназначен

    Вот я и говорю. Есть люди, которые родились, и хоп, у них сразу в ДНК прям прописано понимание, что и для чего предназначено. И есть еще второй тип людей, у них хоть с рождения этого нет, но зато у них есть учебник за подписью Минобрнауки, и в нём написано: ребята, [s]не хулиганьте[/s] вот эти вот технологии предназначено вот для этого-то, а вовсе не для того. Ну и есть третьи — такие лохи, как я, которые ничего не знают и всё [s]в рот суют[/s] проверяют методом научного тыка.

  • Ответить

    ««Мы реализуем стратегию перехода с дорогостоящих решений на СПО, в частности постепенно отказываемся от Oracle в пользу свободно распространяемых баз данных, таких как PostgreSQL и Tibero.»

    Tibero опенсорц ??? да ла-а-а-дно (с)

  • Ответить

    А зачем им вообще коммерческая БД была? Что у них за объём данных такой для неё? Статьи?

    Смешно читать обсуждение, такой объём данных можно хоть в чём хранить.

  • Ответить

    Я вот вообще не понимаю смысла «перевода проектов на …» без всякой причины. Ну вот есть проект он работает, все в порядке. А тут бац — а давайте его переведем на PostgreSQL, Oracle, MySQL и т.п. А зачем? Или может проект и не работал вовсе, а перевод на другую платформу — это попытка оправдать выброшенные вложения? Понятно, когда для нового проекта выбирается платформа на долгие годы с учетом разных факторов — тогда и надо думать!

    По факту есть подозрение, что вот так с нахрапа можно «переводить» только какие-то некритичные проектики, которые на самом деле и не работали до этого, и вряд ли окажутся особо востребованными после «перевода». Вобщем всякий раз читая, что кто-то что-то «перевел на …» можно предполагать удручающую картину для всех IT систем у компании, которая может сначала покупать, а потом одним движением руки брать и менять ключевые инфраструктурные решения (а предыдущий купленный oracle выбросили? А это было разумно?).

  • Ответить

    Ну конечно же, Алексей, вы «не понимаете». Я бы удивился, честное слово, если бы понимание появилось.

    Смысл описан: стоимость владения на порядок ниже, SLA тот же или лучше. Чего же боле? Гешефта? Увы.

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

    Предыдущий оракл не выбросили, он сам умер, от старости.

    Да, а под «нахрапом» вы что подразумеваете? Поясните, пожалуйста.

  • Ответить

    >>Пользуясь случаем, приглашаю сильных PostgreSQL-разработчиков к нам на работу.

    Что вы под этим имеете виду ? Знание встроенного процедурного языка в PostgreSQL, умение использовать explain или знание «потрохов» PostgreSQL ?

  • Ответить

    >> А тут бац — а давайте его переведем на PostgreSQL, Oracle, MySQL и т.п. А зачем

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

    + Если Oracle используется только как БД то перевод не будет очень болезненным, а вот если там половина кода написано на PL/SQL — тогда да возникают проблемы

  • Ответить

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

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

    Для команд, которые специализируются на проектной деятельности, с одной стороны, удобно, когда общий бюджет реализуемых проектов большой, а суммы на оплату услуг по разработке и внедрению в этом бюджете и не выделяются особенно по сравнению с затратами на инфраструктуру (ну вы и сами об этом говорите). С другой стороны, когда общая ситуация на рынке ухудшается и проекты с большими бюджетами оказываются недоступными, удобно перетянуть на себя часть одеяла и просто взять больше денег за сам процесс перехода, перевнедрения и переобучения. Из этого, однако, вовсе не следует, что такое «перевнедрение» и переход экономически обоснованны для заказчика, который мог бы и еще 10 лет сидеть на старой системе и не знать о ее «ущербности».

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

  • Ответить

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

    Вообще, со стороны Oracle и противников Postgres я бы заходил не со стороны сравнения синтетических, придуманных самим Oracle параметром вида «в Postgres нет технологии Oracle Check Performance! Съели? Нет? Вы против check? Вы против performance? Да вы хуже антисемита, гражданин хороший!», а со стороны освещения кейсов, когда кто-то хотел смигрировать, но вот оказалось что никак. Почему никак?

    Непонятно.

  • Ответить

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

    Гм «модернизация» в стиле «Oracle» предполагает открытие кошелька и оплаты очередной лицензии Oracle помимо расходов на железо, в то время как при использовании PostgreSQL этой статьи расходов нет.

  • Ответить

    Юрий, вы рассуждаете примитивно. С точки зрения бизнеса не столь важно, какие системы продавать или внедрять. Важно, однако, понять, насколько масштабные тренды мы обсуждаем. Если переход с Oracle на PostgreSQL — это массовое явление ближайшего будущего, то мы все на этом и будем зарабатывать. Есть, однако, определенные сомнения в том, что другие парни будут на это смотреть опустив руки. На рынке есть Microsoft, есть Tibero и т.д. Вы действительно полагаете, что они так и будут в лоб сравнениями заниматься?

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

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

  • Ответить

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

    Когда я говорю, что стоимость владения оказалась на порядок ниже, то я говорю о СУБД, в контексте статьи. Она получилась в 9-10 раз дешевле в нашем случае. Да, требования к инфраструктуре и персоналу не изменились, это существенная часть костов решения в целом. Ну и что с того? На фоне вечности вообще всё тлен.

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

  • Ответить

    > «модернизация» в стиле «Oracle» предполагает …

    В стиле «Oracle» это как? Если вы сами принимаете решения, то вряд ли «оплату очередной лицензии» вы называли бы модернизацией. А если вы слепо следуете советам «консультантов», то и переход на PostgreSQL приведет вас только к новым тратам на новый переход, пере-пере-переход и т.д. По факту мне известны вполне себе эксплуатируемые системы, которые прошли множество модернизаций и по-прежнему успешно работают на 7/8/9/10 версии оракла, на которых и были первоначально созданы. Т.е. «модернизация» в нормальном случае вообще редко требует замены оракла. Не редко новый оракл покупают потому, что потеряли все документы и дистрибутивы от старого — это по сути единственная причина, но в обосновании ее, естественно, не пишут …

  • Ответить

    «Негативная коннотация» — надо же! Не ищите подвоха — нет его. Не в ваш лично огород эти слова были.

    > Вы хотите поговорить о стоимости техподдержки Оракла и условиях ее пролонгации/возобновления?

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

    > Она получилась в 9−10 раз дешевле в нашем случае.

    Сколько же вам лишнего и ненужного ваши «консультанты» насчитали — просто жуть …

    Попробую предположить — у вас был Oracle в версии Enterprise или требовался переход на Enterprise со Standart?

    Вообще у Oracle гигантский разрыв по цене при переходе от Standart к Enterprise версии. Но по факту многие проекты, которые зачем-то потратились на Enterprise могли бы успешно работать и на Standart без проблем. Типичные сравнения Oracle с MS SQL и IBM DB2 показывают, что этот продукт в полной Enterprise версии по стоимости владения заметно дороже своих непосредственных конкурентов — что уж говорить о бесплатном софте.

    А вам пока не доводилось переводить на PostgreSQL с DB2? Вот уж где специалисты сидят по навязыванию всего своего так это в IBM — если однажды сел на эту платформу, то соскочить бывает уже очень трудно.

  • Ответить

    Алексей, я мыслю не примитивно, я мыслю конкретно.

    Например, когда Oracle заявляет, что mission critical это синоним Oracle, а я вижу несколькочасовой даунтайм у крупнейшего банка страны, с которым после этого ничего фатального не случилось, у меня появляется мнение, что может быть, клиентам российских компаний с ненавязчивым сервисом, наплевать на трёхчасовой простой в течение года и это никак не связывается на бизнесе, например?

    И посылка про абсолютную надёжность Оракла она не только неверна (хотя сломать, конечно, можно что угодно), но и не нужна для бизнеса? Она ложная?

    Так может быть таких ложных посылок при «выборе» у Оракла не одна, и не две?

    (это то, о чём я думаю, конечно)

  • Ответить

    > Так может быть таких ложных посылок при «выборе» у Оракла не одна, и не две?

    Точно больше.

    > И посылка про абсолютную надёжность Оракла она не только неверна (хотя сломать, конечно, можно что угодно), но и не нужна для бизнеса?

    Гипотетически надежность нужна. Но СУБД чаще всего является намного более надежным звеном, чем другие звенья системы. Так что Oracle там или что-то другое как правило не очень влияет на картину в целом.

    > клиентам российских компаний с ненавязчивым сервисом, наплевать

    Это как пользователям метро — им вроде и не плевать, но если вдруг не едет метро, то на это можно списать все что угодно и идти пить пиво.

    Для бизнеса, который работает на основе своих IT-систем, простой означает отсутвтие заработка. И тут все определяется масштабом и наличием у пользователей альтернатив. Если, например, легла ИТ-система ритейловой сети и ее магазины перешли на оплату только наличными, то так можно и неделю протянуть. А вот если продажи стали совсем (кассы интегрированы в систему), то это ежеминутные потери, которые можно непосредственно подсчитать и понять, что стоимость СУБД, какую ни возьми, намного меньше этих потерь.

    Oracle действительно является mission critical и, пожалуй, да — именно Oracle самая устойчивая (хотя по данному параметру разницу с DB2 найти трудно). Именно этим сама Oracle объясняет свою высокую цену (а чем им еще объяснять?). Но вы правы в том, что использование Oracle вообще никак не говорит о надежности системы в целом и важности критерия надежности для бизнеса вообще.

  • Ответить

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

    Ну скажем оракловые best practices (и стандартное поведение интеграторов и прочих программистов) — они хорошие. И банки оттого падают на три часа. Всего на три часа.

    А, к примеру, у опенсорсных баз (не буду называть) — best practices это как больше пятаков на грош получить. А отказоустойчивость делается палкой, веревкой и розгами.
    И банк, построенный на этих практиках, упадет может даже на два часа, но потом половины транзакций не найдет.

  • Ответить

    Фиксация best practices, конечно же, сильный аргумент, но потеря половины транзакций выглядит как FUD, если честно

    Мне кажется, что на корпоративном рынке это проще формулируется: среди внедренцев Oracle на упырей напороться крайне сложно, а вот среди внедренцев PostgreSQL…

  • Ответить

    … а вот среди внедренцев Postgresql — хрен пойми.

    У меня опыт с Postgresql — больше 15 лет и то меня Космодемьянский с моими практиками оборжал. Я, конечно, не настоящий сварщик и никаких банковских систем отродясь не делал и все такое.

  • Ответить

    > Алексей, а в чем и — главное — как измеряется устойчивость СУБД?

    Временем восстановления после отказа (в секундах, минутах, часах).
    Путем проведения дурацких тестов по разным методикам, активно пропагандируемым разными поставщиками СУБД.

  • Ответить

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

    Организация, оказывающая услуги по обслуживанию пользователей ЕИС,
    сообщает о проведении регламентных работ
    в период с 01.04.2016 22:00 по 02.04.2016 18:00

  • Ответить

    > сообщает о проведении регламентных работ …

    Можно не сомневаться, что никакая смена СУБД им не поможет — причины простоев совсем в другом.

    Вот вам еще пример. Журналисты CNEWS накинулись на Сбербанк http://www.cnews.ru/news/top/2016-04-01_sberbank_snova_bezalternativno_zakupaet_tehpodderzhku

    По сути за то, что Сбербанк покупает техподдержку Оракла у Оракла. Где же ему еще ее покупать? Через цепочку дармоедов? Так в Оракле и своих хватает, чтобы цене не падать …

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

  • Ответить

    > > Алексей, а в чем и — главное — как измеряется устойчивость СУБД?
    > Временем восстановления после отказа (в секундах, минутах, часах).

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

    > … причины простоев совсем в другом.

    техника сама по себе не увеличивает и не уменьшает время восстановления, важно кто проектирует систему, и кто её эксплуатирует.

  • Ответить

    Алексей, зачем вы ваньку-то валяете? Когда существует риск, что поставщик откажется от ВСЕХ обязательств под предлогом того, что обязан исполнять решения правительства США, все разговоры о надежности, аптайме и лучших практиках моментально теряют смысл.
    Надежность Oracle, Microsoft, HP, Cisco, Sun, Visa, Intel, IBM, Dell и прочая в настоящий момент равна нулю. Это ощутили вообще все, включая полностью коммерческие компании с полностью иностранными инвесторами. Все сидим на пороховой бочке, отказ в обслуживании без восстановления может случится у кого угодно и когда угодно. А SLA CTO и CEO только смогут распечатать, чтобы ими подтереться.

  • Ответить

    >>ообще с банками особая история

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

  • Ответить

    Про Ria я написал, что решение понятное и во многом политически мотивированное. У них действительно есть описанная проблема с правительством США.

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

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

    Это распространенная «пугалка», расчитанная на ламера. Мол завтра Microsoft, HP и прочие что-то там подкрутят и все станет колом. Это откровенная лапша на уши, которая не учитывает того простого факта, что «подкрутить» может и противоположная сторона (обиженный пользователь), что позволит ей благополучно использовать имеющиеся информационные системы много-много-много лет. Это если речь идет об on-premise решениях, находящихся в полном распоряжении пользователя. А вот всякие SaaS и Cloud — тут да — все можно выключить «на раз».

  • Ответить

    > а это точно от СУБД зависит?

    Время восстановления СУБД после отказа точно зависит от СУБД.

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

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

  • Ответить

    > немалые деньги …

    Как сказать. Вот тут много больше, например, http://www.infoworld.com/article/2673122/techology-business/oracle-wins—88-5-million-air-force-contract.html

    > не несет ответственности за потерю данных …

    Oracle, как и другие крупные IT-компании сейчас тащит клиентов в облако. Вот в своем облаке согласно SLA провайдер уже вполне отвечает за потери данных. Тут, однако, мы выясняем, что все эти Cloud и SaaS хостятся не в России (на сегодня только SAP заявила о скором развертывании облачных сервисов именно в России). И риски использования таких облачных сервисов (включая возможность их мгновенного отключения по команде из Госдепа) вполне очевидны.

    Насколько я понимаю текущую ситуацию, все крупные IT-компании уже получили вполне четкий «намек», что без развертывания хостинга в России «каши не будет» — ушли думать и тянут время (а вдруг «ишак сдохнет»). А крупные пользователи, вроде Сбера, просто закрывают свои текущие вопросы на ближайший год-два и думают, в какую сторону развивать свои IT-системы дальше (или просто ждут, что все решится само-собой).

  • Ответить

    > утверждение, что по приказу правительства США какие-либо системы могут взять и перестать работать — это уже конспирология и вымысел.

    вы просто не в теме. в рамках ПД ИТР люди в погонах давно уже запрещают использовать ту же циску в критичных системах — потому что закладки.

    еще для расширения кругозора: NSA ANT.

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

    > Техподдержку очередную могут не продать — да.

    или перестать само оборудование/ПО продавать (см Cisco ФТС). а если там большая инфраструктура, завязанная на одного этого поставщика?

    > Мол завтра Microsoft, HP и прочие что-то там подкрутят и все станет колом.

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

    > > а это точно от СУБД зависит?
    > Время восстановления СУБД после отказа точно зависит от СУБД.

    но не только, время восстановления зависит от комплекса факторов (архитектура системы, мониторинг, персонал, резерв), в котором фактор СУБД конечно играет роль, но только если вы положили таки все яйца в одну корзину этой самой СУБД. и вы это сами прекрасно понимаете:

    > В реальной жизни огромное значение имеют всякие организационные и прочие технические факторы

    > время восстановления будет равно времени поиска запчастей на замену включая срочную доставку из Лондона, так на складе в России их никто не держит

    если эксплуатанты безголовые, и не положили всё что можно в ЗИП — да, так и будет. причем тут СУБД? не причем.

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

  • Ответить

    > оборудование/ПО

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

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

    > можно и нужно сравнивать, всесторонне …
    Я же написал. Что есть куча дурацких (зачастую конкурирующих) методик от разных производителей СУБД. Читайте, пользуйтесь, сравнивайте, наслаждайтесь …

  • Ответить
    Владимир Мяу и компания

    Алексей, даже в опен сорсном ПО, уж куда прозрачней, люди иногда находят закладки типа HeartBleed. О каком выявлении закладок в топологии микросхем вы нам тут рассказываете по секрету всему свету? :)

  • Ответить

    > даже про оборудование я вам расскажу, что есть способы выявления закладок

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

    > Именно поэтому, например, нет проблем с закладками, если даже микросхема произведена на западе … процессорами Байкал

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

    > есть куча дурацких (зачастую конкурирующих) методик от разных производителей СУБД

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

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

  • Ответить

    > а вот это уже конспирология :)

    Любовь к конспирологии не помешала Крису Картеру снять Lone Gunners с радиоуправляемым самолетом, влетающим в башни-близнецы, за полгода до 9/11. Наличие даже самых идиотских конспирологических теорий не является доказательством того, будто скрытных операций не существует — шпионаж, саботаж, подкуп и всё остальное существует. Даже когда кто-то дает взятку заведке в садике, чтобы туда взяли ребенка, это тоже своего рода бытовая конспирология. Ведь они будут всё отрицать. :D

  • Ответить

    >Это как пользователям метро — им вроде и не плевать, но если вдруг не едет >метро, то на это можно списать все что угодно и идти пить пиво.

    Кстати в метро Oracle и стоит больше 15 лет уже. Периодически падает этот mission critical самым невообразимым образом. В недрах RAC возникает какой то неизвестный «проблемс» и система наглухо встает до ручного перезапуска БД, а то и всего железа… Ессно тех. поддержки там нет, потому эскалировать проблему некуда. Слава богу возникает редко.
    На пассажиров не сказывалось до поры до времени, т.к. не было прямой связи. Но с недавнего времени периодически сказывается… можете поискать в новостях например сколько раз за последний год отказывала сеть автоматов по продаже билетов или не работали льготы по парковке. Не очень критично конечно… Слава богу к поездам не привязано :)

  • Ответить

    > Периодически падает этот mission critical самым невообразимым образом

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

  • Ответить

    Ахахаха, значит отключение банков от Визы и Мастера, закрытие сервисов Google и Apple в Крыму и закрытие Добролета нам только померещилось? Так же как и массовые отказы железячников от поставок элементов и оборудования?

  • Ответить

    Алексей, ну вы же типа сэйлз, как же вы не понимаете, что ваше mission critical без расширенной поддержки никто не собирается покупать? В ней как раз весь смысл и главное отличие от OpenSource.
    И вот представьте, встала колом Oracle на оборудовании HP, а поддержку оказывать никто не собирается, пункт такой-то резолюции OFAC и всё такое. Ну и нахрена тогда ваша проприетарная тыква и ваше американское оборудование? Сползание на OpenSource или решения более адекватных людей — уже два года как вопрос business continuity, а не экономии или оптимизации.
    Просто никто об этом не будет прямо говорить, потому что большинство вендоров санкции как могут игнорируют, хотя уже давно обязаны целые отрасли российской экономики остановить.

  • Ответить

    Правильно.
    На очереди продукты Google, Adobe, Microsoft, IBM и прочих.
    Тем более полно замен. Пересадим дизайнеров на GIMP, Blender и заживем наконец как люди.

  • Ответить

    >>По моей практике главное, чтобы была внятная система восстановления работоспособности. Чтобы люди знали, что конкретно им нужно делать в случае аварии, чтобы запчасти на складах лежали, чтобы бэкапы были работоспособные и свежие и т. п.
    Гм те люди покупая Oracle платят за «инструкции по восстановлению данных» ?

  • Ответить

    Павел, всех устраивает и качество, и стоимость и никто не хочет никуда пересаживаться.
    Однако, что вы будете делать, если вендор, на решениях которого построена вся ваша инфраструктура, откажется с вами работать? И это не иллюзорный риск.
    Уже 100% частные, со 100% иностранными инвесторами компании заполняют многостраничные опросники, где доказывают, что не собираются перепродавать оборудование и софт санкционным компаниям. Пока все заявки удовлетворяются, просто сроки поставки неприлично растянулись и это, кстати, начинает становится проблемой.
    А что если завтра придет отказ? Ну какой-нибудь придурок клерк там решит, что вы там под что-то подпадаете или из ваших ответов чего-то там не ясно? А придурков-клерков там вагон, кстати. А вслед за этим придет автоматический отказ от всех обязательств по расширенной поддержке и вся прелесть ведущих решений тут же превратится в тыкву.
    А что если не дурак-клерк, а действительно решат, что нарушаете?
    И что вы скажете инвесторам? Руками разведете — «риски инвестирования в Россию»? Так они спросят: «Ты что, идиот? За два года не понял, что такой риск существует и он может реализоваться?»

  • Ответить

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

    > А что если завтра придет отказ?
    А если бы он вез патроны? (c) :)

    Мне однажды немцы сервер затерли. И оказалось, что так можно. Даже пункт какой-то в договоре есть.

    Я не верю в универсальные решения. Бизнес основан на рисках.

  • Ответить
    Владимир Мяу и компания

    > Завидую тем, кого все устраивает.

    О, так вы из тех, кто вечно всем недоволен? :D

    > Мне однажды немцы сервер затерли.

    Как так?

    > Бизнес основан на рисках.

    А я, наивный, думал, что на управлении рисками.

  • Ответить

    > что вы будете делать, если вендор, на решениях которого построена вся ваша инфраструктура, откажется с вами работать?

    А ничего не делать. Вот есть инфраструктрура, она работает, с ней все в порядке, запчасти на некоторое время имеются. Что и зачем нужно делать?

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

    > И вот представьте, встала колом Oracle на оборудовании HP, а поддержку оказывать никто не собирается, пункт такой-то резолюции OFAC и всё такое. …

    У вас встала? Вам оказать? Или вы о сферическом коне?

    > и вся прелесть ведущих решений тут же превратится в тыкву

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

  • Ответить

    > Гм те люди покупая Oracle платят за «инструкции по восстановлению данных» ?

    Редко когда. Обычно за это не платят, но хотят получить бесплатно, когда идет сдача проекта. Просто в проектах с Oracle бюджета обычно хватает (раньше хватало) на такой небольшой «гешефт» клиенту и интеграторы (пусть неохотно), но делают. А вот в проектах с небольшим бюджетом ничего «лишнего» уже не помещается …

  • Ответить

    > О, так вы из тех, кто вечно всем недоволен? :D
    Ага. Вечно не нравится что-то.
    В Nikon и Canon, PHP и node.js, Linux и Windows.
    Без шуток, завидую адептам того же Nikon или Oracle.

    > А я, наивный, думал, что на управлении рисками.
    Управление — следствие их наличия, разве нет?

    > Как так?
    Натурально. Захожу через rescue, а там чистая ось.
    Ну я думаю не специально конечно. Хотя как знать, может санкция какая была:)
    Поменьше паники.

  • Ответить

    > И ничего — еще 40 лет летали себе помаленьку.
    Это скучно. Кричать в панике «Все пропало» ведь куда интересней.
    Помню сколько слюней брызгало из новостей в 2008-м году на тему кризиса. Столько «аналитиков» поднялось на этой теме.

  • Ответить
    Владимир Мяу и компания

    > А ничего не делать. Вот есть инфраструктрура,
    > она работает, с ней все в порядке, запчасти на
    > некоторое время имеются. Что и зачем нужно делать?

    Ахаха. :D

    > а также банальная поддержка существующих и вполне
    > рабочих систем.

    Это где вы видели банальные вполне рабочие системы? Я понимаю, АвтоВАЗ мог с 60 года аж по 2010 штамповать одну и ту же модель жигулей. Вот это — ДА…. А в реальности в любую систему приходится постоянно вносить множество изменений, как программных (в силу меняющихся условий бизнес-среды, законодательства, предпочтений и платежеспособности клиентов и т.д.), так и аппаратных — когда какие-то компоненты выходят из строя и их нельзя (или нецелесообразно) заменить на другие такие же, или когда начинает не хватает установленных мощностей. Да что я вам рассказываю, мне кажется, любой эксплуатант регулярно со всем этим сталкивается.

    > И ничего — еще 40 лет летали себе помаленьку.

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

  • Ответить

    > > А я, наивный, думал, что на управлении рисками.
    >
    > Управление — следствие их наличия, разве нет?

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

    > Поменьше паники.

    Действительно. «Прячь голову в песок и спи спокойно.» :))

  • Ответить

    > Это где вы видели банальные вполне рабочие системы?

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

  • Ответить

    > Ну ага. Только вы сказали по-другому. Сказать, что бизнес основан на рисках — это всё равно, что сказать, будто урожай картофеля основан на колорадских жуках. Ж)
    Наверное я непонятно написал, извиняюсь. В ГК РФ так написано о предпринимательстве: «осуществляемая на свой риск деятельность».

    > Действительно. «Прячь голову в песок и спи спокойно.» :))
    Ну зачем же сразу песок? А вот про сон верно.

    > А в реальности в любую систему приходится постоянно вносить множество изменений
    Ага, пойду пропатчу MySQL, а то скучно живется:)

  • Ответить
    Владимир Мяу и компания

    > Наверное я непонятно написал, извиняюсь.
    > В ГК РФ так написано о предпринимательстве:
    > «осуществляемая на свой риск деятельность».

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

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

  • Ответить

    Те́хника (др.-греч. τεχνικός от τέχνη — искусство, мастерство, умение) — обобщающее наименование технических средств (устройств). Понятие техники охватывает технические изделия, ранее не существовавшие в природе и изготовленные человеком для осуществления какой-либо деятельности — машины, механизмы, оборудование, аппараты, приспособления, инструменты, приборы и т. д. — а также системы взаимосвязанных технических устройств. Основное назначение техники — избавление человека от выполнения физически тяжёлой или рутинной (однообразной) работы, чтобы предоставить ему больше времени для творческих занятий, облегчить его повседневную жизнь.
    Различные технические устройства позволяют значительно повысить эффективность и производительность труда, более рационально использовать природные ресурсы, а также снизить вероятность ошибки человека при выполнении каких-либо сложных операций.
    И т.д. (википедия вам в помощь …)

  • Ответить
    Владимир Мяу и компания

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

  • Ответить

    > принятие — это крайний случай
    Принятие или нет — это уже реакция на риск, вы не находите?
    Или риски возникают после их страхования?:)

  • Ответить
    Владимир Мяу и компания

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

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

    Второй этап — это ранжирование. Наверху списка должны оказаться самые разрушительные и одновременно высоко вероятные риски. И наоборот, низковероятные и/или малоопасные риски должны оказаться где-то в хвосте, так, что в большинстве случаев никто до них вообще никогда не дойдет, как будто их и нет.

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

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

  • Ответить

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

  • Ответить

    > Но негативные последствия — это не риски.
    Правильно. Поэтому «в основном под словом риск чаще всего понимают вероятность получения неблагоприятного результата».

    > Поэтому первый этап управления рисками…
    А вы описываете процесс управление рисками. Не понятно зачем.

  • Ответить
    Владимир Мяу и компания

    Алексей, я хотел узнать, что такое технический смысл системы? Я не хотел узнать, что такое техника. Техника, механизация, информация и прочие нанотехнологии, повышающие удои, в данном случае лично мне не интересны. :)

    Я понимаю, когда у системы есть коммерческий смысл. Когда у нее есть социальный смысл. Или психологический, или даже метафизический. А технический?

    Может я туплю конечно. Но техника ради техники — это пфф…

  • Ответить
    Владимир Мяу и компания

    > предпринимательская деятельность — это не столько
    > брать риски на себя, сколько управлять ими. :)

    Даже больше, пример «чистого» принятия рисков — это игорная зависимость, болезнь, когда человек постоянно ходит в казино, делает какие-то ставки и т.д. Такой человек прекрасно осознаёт риск — всё проиграть, но из всех вариантов отработки риска выбирает только один — принять риск на себя. Так вот, предпринимательство — это совсем не то же самое, что игорная болезнь.

  • Ответить

    > Чтобы было понятней, что предпринимательская деятельность — это не столько брать риски на себя, сколько управлять ими. :)
    Конечно. Предпринимательская деятельность подразумевает риски.
    А как вы ими управляете — ваше личное дело.

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

  • Ответить
    Владимир Мяу и компания

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

  • Ответить

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

  • Ответить
    Владимир Мяу и компания

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

    «Казалось бы, при чём здесь [s]Лужков[/s] предпринимательство?»

  • Ответить

    > «Казалось бы, при чём здесь [s]Лужков[/s] предпринимательство?»

    Ну вот вы же пишите:

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

    Значит есть отличия?

  • Ответить

    Технический смысл у системы есть, если она изготовленна (разработана, внедрена) для осуществления какой-либо деятельности и избавляет человека от выполнения физически тяжёлой или рутинной (однообразной) работы или позволяет значительно повысить эффективность и производительность труда, более рационально использовать природные ресурсы, а также снизить вероятность ошибки человека при выполнении каких-либо сложных операций.
    Впрочем, вы явно тяготеете к абстракциям. Мне кажется, что когда говориться, что «система не имеет смысла с технической/коммерческой и пр. точки зрения», то этого вполне достаточно для общего понимания сказанного. Особенно, если это имеет опосредованное отношение к основной теме …

  • Ответить

    Таможня лежала три дня …

    «при восстановлении базы данных таможни после сбоя были потери по процедурам, открытым в период с 25 марта, »

    Профакапили архивлоги ?

  • Ответить

    >>Ну скажем оракловые best practices (и стандартное поведение интеграторов и прочих программистов) — они хорошие. И банки оттого падают на три часа. Всего на три часа.
    Вероятно Вы ровно те падения на три часа имеете в виду :) Они не были связаны с самим Ораклом. Прогрессирующий дибилизм рабсилы (даже в ИТ) плюс по**изм конкретного подразделения / начальник недосмотрел — какая формулировка Вам больше приглянется.

    >>А, к примеру, у опенсорсных баз (не буду называть) — best practices это как больше пятаков на грош получить. А отказоустойчивость делается палкой, веревкой и розгами.
    А есть хорошие локальные команды на Postgres? Пул ресурсов есть?