Сравниваем TCO покупки «железа» и аренды облака



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

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

    Цель этой статьи — разобраться в методике TCO для разных вариантов получения права пользования ИТ-инфраструктурой и провести соответствующие расчеты, дабы выявить наиболее экономически эффективную альтернативу.

    РЕЗУЛЬТАТАМИ ИССЛЕДОВАНИЯ ЯВЛЯЮТСЯ (UPD)

    • понимание необходимости учитывать уровень отказоустойчивости ИТ-систем как ключевую характеристику «to compare apples to apples»;
    • расчет совокупной стоимости владения ИТ-инфраструктурой для двух шаблонов использования: ERP-система и веб-ресурсы спортивного портала;
    • сравнительный анализ совокупных затрат на владение собственной ИТ-инфраструктурой и на аренду облака;
    • факторный анализ экономии на преимуществах облачных технологий и выявление наиболее благоприятных шаблонов использования облака.

    Что такое TCO?


    Совокупная стоимость владения или стоимость жизненного цикла (англ. Total Cost of Ownership, TCO,) — это общая величина целевых затрат, которые вынужден нести владелец с момента начала реализации вступления в состояние владения до момента выхода из состояния владения и исполнения владельцем полного объёма обязательств, связанных с владением.

    Методика TCO была разработана в конце 80-х годов XX века компанией Gartner Group для расчета финансовых затрат на владение компьютерами на платформе Wintel (MS Windows+Intel). Она была усовершенствована в 1994 г. фирмой Interpose и переработана в полноценную модель анализа финансовой стороны использования информационных технологий. При таком расчете TCO затраты на создание аппаратной платформы, покупка лицензий на программное обеспечение, расходы на оплату труда ИТ-специалистов и прочее — это так называемые «прямые» или «бюджетные» расходы. Но есть еще неявные финансовые вливания в содержание своей ИТ-инфраструктуры, затраты и потери, связанные с её функционированием и так далее. Причем, авторы методики TCO утверждают, что такие издержки составляют основную долю совокупной стоимости владения ИТ-инфраструктурой. Эти затраты называются «непрямыми расходами», и согласно многолетней практике расчетов TCO превышают упомянутые выше «прямые расходы» в 3–5 раз.

    То есть на самом деле предприятия тратят на содержание своего «железа» гораздо больше средств, чем предполагают. Почему так происходит и можно ли оптимизировать затраты на собственную IT-инфраструктуру?

    Именно эти цели и преследует методика TCO. Но для того, чтобы понять, как можно управлять расходами на содержание, нужно сначала прояснить, как они рассчитываются [1].

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

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

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

    Как мы рекомендуем считать совокупную стоимость владения ИТ-инфраструктурой и почему


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

    Наиболее популярной альтернативой покупки собственного оборудования и ПО виртуализации является аренда готовой ИТ-инфраструктуры в облаке по модели IaaS (англ. Infrastructure as a Service — Инфраструктура как услуга).

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

    Вам уже удалось провести необходимые расчеты? Теперь можно сравнить? Да, если вы сделали это правильно.

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

    В общем, бизнес хотел бы получить 99,99% доступности. Однако создание решения такого уровня потребует значительных инвестиций. Таким уровнем отказоустойчивости обладает, например, решение на основе двух СХД с синхронным зеркалированием, расположенных в паре географически удаленных друг от друга центров обработки данных. Не удивительно, что стоимость такой услуги будет в 2 раза выше.

    Каждому ли необходимо такое решение? Конечно, нет. Если мы говорим об ожидаемом уровне доступности в 99,95% или 4 часа 23 минуты простоя в год, мы ожидаемо проигрываем всего 0,04% аптайма решению, которое в 2 раза дороже. В невисокосном году 8760 часов, а значит, если не произойдет природных катакликзмов, от которых нас спасло бы только катастрофоустойчивое решение, мы добавляем всего 3,5 часа в год ко времени безотказной работы ИТ-инфраструктуры в год, вкладывая значительные средства.

    Итак, мы подходим к вопросу сколько стоит минута простоя для вашего бизнеса и какой уровень отказоустойчивости вам нужен. Знакомы ли вы со страшным словосочетанием “cost of downtime”?



    Согласно опросу, проведенному институтом Ponemon в 2014 году, средняя стоимость минутного простоя составляет 7 900 долларов США по сравнению с 5 600 долларов США за минуту четырьмя годами ранее. Несмотря на то, что эти цифры могут выглядеть катастрофическими, они легко могут быть отброшены как релевантные только для нескольких крупнейших компаний в США.

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

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

    Прямые потери дохода от продаж




    Это может показаться тривиальным, но предполагая, что доход генерируется онлайн или строго зависит от работы ИТ, вам потребуется просто разделить сумму годовых продаж на 525 600 (60 мин. X 24 часа x 365 дней) для определения средней стоимости простоя в минуту. Таким образом, формула убытка может выглядеть примерно так:



    Где t обозначает количество минут простоя вашей IT-инфраструктуры.

    Стоимость потерь в производительности сотрудников


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



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

    Стоимость восстановления ИТ-инфраструктуры


    Стоимость времени ИТ-персонала, занятого восстановлением вашей системы из резервной копии или заменой вышедшего из строя оборудования.



    Где N_IT обозначает количество сотрудников, занятых в ИТ-операциях по восстановлению вместо иной полезной для бизнеса деятельности, а t' обозначает время, необходимое для исправления проблем всех затронутых систем и их возврата к нормальному состоянию.

    Прогнозируемая потеря дохода из-за снижения лояльности клиентов


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



    Где r обозначает средний показатель (rate, процент) снижения повторных продаж, а Д — доход от повторных продаж за год.

    Прогнозируемая потеря дохода из-за ущерба репутации


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



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

    Таким образом, формула общей стоимости простоя (TCoDT, total cost of downtime) может выглядеть примерно так:



    Где У_продаж, С_время сотрудников, С_восстан. IT, У_лоял, У_репутац соответственно означают потерянный доход, стоимость потерь из-за снижения производительности сотрудников, стоимость восстановления ИТ-инфраструктуры, прогнозируемую потерю повторных продаж и прогнозируемые потери из-за ущерба репутации.

    В качестве примера рассмотрим интернет-магазин с 50 миллионами рублей продаж и 15 сотрудниками в штате. Почасовые 5708 рублей или чуть более 95 рублей в минуту являются прямыми потерями дохода.

    Какой продолжительности ожидаемый простой в течение года ждет компанию?

    Многое зависит от того как организована IT-система этого бизнеса. Хорошо изученными и типовыми объектами являются публичные центры обработки данных. Uptime Institute создал уровневую систему классификации для систематической оценки различных сооружений и оборудования центров обработки данных с точки зрения потенциальной производительности инфраструктуры или способности безотказно работать (uptime). Система состоит из четырех уровней, каждый уровень включает в себя требования нижних уровней (Tier):

    • Tier I: Basic Capacity — базовый потенциал, инфраструктура без резервирования;
    • Tier II: Redundant Capacity Components — дублирование критически важных компонентов, инфраструктура с резервированием;
    • Tier III: Concurrently Maintainable — инфраструктура с возможностью параллельного ремонта/обслуживания без остановки работы;
    • Tier IV: Fault Tolerant — отказоустойчивая инфраструктура.



    Хотя Uptime Institute удалил информацию об «ожидаемом в год простое» из Tier Standard в 2009 году [2,3], мы можем сделать выводы о том, что ранее, публикуя эти данные, эксперты по эксплуатации дата-центров обобщили информацию о сбоях и пришли к выводу, что базовая инфраструктура без резервирования ожидаемо безотказно работает 99,671% в год или простаивает из-за аварий 28,8 часа.

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


    «Плачевное» состояние серверных может стать причиной крупных аварий

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



    Например, Доступность = 99,671% (локальный ЦОД без резервирования) × 99,671% (ИТ оборудование без резервирования) = 99,343% или около 2,5 суток ожидаемого простоя, если сбои вызваны разными причинами и в разное время.

    Предположим, у вас достаточно хорошо организованная деятельность, и простой ИТ-инфраструктуры продолжается не более девяти часов в год, немного не дотягивая до трех девяток (99,9%). Это означает, что все работники, затронутые сбоем (предположительно 2/3), не могли нормально работать, по крайней мере, в течение этого периода времени. Если мы возьмем среднюю почасовую заработную плату с налогами и сборами в 500 рублей, это обойдется компании в 45000 рублей по причине потери производительности.

    Логично, что ИТ-команда потратит еще какое-то времени на выяснение того, что пошло не так, чтобы затем предотвратить повторные сбои. Представьте, что вашим IT-гениям потребуется 50 часов (800 рублей/час), чтобы всё исправить. Это время работники могли бы потратить на решения задач развития вашего бизнеса. Даже если вы выделите только одного сотрудника на эту проблему, это дополнительные 40000 рублей, которые нужно включить в стоимость восстановления IT.

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

    Итак, оценочно добавим убыток в размере 50000 рублей, чтобы учесть дополнительные 1% прогнозируемых потерь на повторных продажах за год и 35000 рублей за 2%-ную потерю продаж по отзывам и рекомендациям, вызванных простоем. Вырисовывается неприятная картина, но давайте сложим все это:
    Потери продаж
    51 372
    Потери производительности
    45 000
    Стоимость восстановления IT
    40 000
    Потери на повторных продажах
    50 000
    Потери на продажах по отзывам
    35 000
    Общая стоимость простоя IT- инфраструктуры
    221 372 руб.
    Быстро становится понятно, почему существует значительный разрыв в том, как малые предприятия и корпорации подходят к оценке потерь от простоя — от измерения последствий до давно ясной потребности в выстраивании процедур реагирования и восстановления.

    Согласно опросу представителей крупного бизнеса США, 37% организаций оценивают день простоя в потери более 10 000 долларов США, что перекликается с 38% респондентов, сообщивших о годовом доходе более 10 миллионов долларов. Таким образом, хотя цифры для малого и среднего бизнеса значительно ниже, чем фактические потери за время простоя для корпораций, также ясно, что даже малые предприятия, которые полагаются на современные технологии, должны серьезно относиться к проблеме безотказной работы с учетом их масштаба.

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

    Статья 4 Закона от 24 июля 2007 № 209-ФЗ и постановление Правительства РФ от 4 апреля 2016 № 265 сообщают нам о доходе и количестве сотрудников, которые являются критериями получения бизнесом определенного законного статуса.
    Предельное значение среднесписочной численности работников за предыдущий календарный год
    Доходы за год по правилам налогового учета не превысят:

    15 человек — для микропредприятий;


    16–100 человек — для малых предприятий;


    101–250 человек — для средних предприятий


    120 млн руб. — для микропредприятий;


    800 млн руб. — для малых предприятий;


    2000 млн руб. — для средних предприятий


    Таким образом, даже рассмотренный нами пример микропредприятия с 15 работниками и 50 млн. рублей годового дохода показывает, что незначительный простой 0,1% в год приносит бизнесу серьезные убытки, которые могут составить существенный процент от годовой прибыли. Именно поэтому малым и средним предприятиям необходимо реализовывать ИТ-систему с уровнем надежности близким к 99,95%. Такой выбор является «золотой серединой» между дополнительными затратами на катастрофоустойчивые решения и минимизацией убытков от простоя менее надежных систем.

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

    В рамках этой работы, мы обозначим целевой уровень бесперебойности работы ИТ на уровне 99,95% в год. Далее перейдем к расчету совокупной стоимости владения для разных моделей использования ИТ-инфраструктуры только с заданным уровнем ожидаемой отказоустойчивости.

    TCO on-premise решения


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

    • ERP на 350 пользователей
    • Веб-сайт популярного спортивного портала

    Расчет TCO будем производить на периоды 3 и 5 лет.

    Приобретение собственного оборудования


    Для выполнения вычислений под эти задачи будет использоваться следующая конфигурация оборудования. Ориентируясь на среднерыночные цены для high-end серверного оборудования и mid-range СХД, получаем ожидаемые затраты:
    Оборудование
    Цена
    3+1 Серверы: CPU Xeon® E5 4 core 2,6GHz, RAM 64 Gb, 2х10Gb
    1 500 000 рублей
    СХД SAS общим объемом 11 Тб (оперативные данные до 1Тб RAID1, остальные исторические RAID6)
    2 300 000 рублей
    1+1 Коммутаторы
    200 000 рублей
    Почему mid-range СХД? Средний уровень — это уже серьезные системы, в которых продумана защита от большинства сценариев сбоя, выше уровень сопровождения (включая возможность удаленного мониторинга сервис-центром и замены дисков on-site по гарантии).

    Надежность таких систем исчисляется количеством «девяток», порядка, к примеру 99,999% заявленного времени бесперебойной работы в год. Большинство операций ремонта и многие операции апгрейда железа и ПО (увы, не все), могут производиться без прерывания работы. А мы помним о том, что выстаиваем систему с общей отказоустойчивостью не ниже 99,95%. Таким образом, мы экономим, не покупая high-end СХД, которая стоит в несколько раз дороже, но и не теряем в бесперебойности работы.

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

    Итак, мы получили первые капитальные затраты на покупку оборудования. Они составили 3 000 000 рублей.

    На этом можно было бы закончить с затратами на оборудование, но так как мы рассчитываем TCO и на 5 лет, а стандартная гарантия заканчивается зачастую по истечению 3 лет, добавим стоимость продления гарантийного обслуживания на 2 года. Так как стоимость продления гарантии различается для каждого вендора, оценочно обозначим эти затраты как 20% от стоимости оборудования за 2 года или 600 000 рублей в нашем случае. Расчет процентного соотношения стоимости постгарантийного обслуживания мы проводили на примере техники HPE [4].

    Площадка для размещения: ЦОД или on-premise


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

    Чтобы как-то оценить затраты мы обратились к исследованию «Оценка совокупной стоимости владения центром обработки данных» Л.А. Пироговой, В.И. Грекул и Б.Е. Поклонова [5]. Исходя из анализа рынка строительства коммерческих ЦОДов, по результатам регрессионного моделирования капитальных затрат на строительство 1 стойки в ЦОДе в Москве авторы приходят к доверительному интервалу от 59 до 88 тысяч долларов США. Таким образом, даже экономя на масштабе, чтобы получить надежную площадку для размещения оборудования, которая может соответствовать ожидаемому простою оборудования не ниже 99,95%, необходимо потратить около 4,5 млн. рублей только на строительство и оборудование без учета операционных расходов. Конечно, вариант таких непрофильных затрат отпадает почти для всех организаций.

    Логичным вариантом является размещение серверов или аренда стойки в коммерческом ЦОДе, так называемый Colocation. Рынок услуг коммерческих дата-центров хорошо развит, такой подход к размещению оборудования стал общепринятым по причинам очевидной экономической целесообразности.

    Размещение 6 юнитов в ЦОДе Tier III (резервирование систем электропитания, охлаждения, телеком инфраструктуры и систем пожаротушения, возможность ремонта систем без остановки работы серверной комнаты) в Москве по среднерыночным ценам с учетом дополнительного к базовым тарифам расхода электроэнергии и гарантированным каналом составит порядка 40 000 рублей в месяц.

    Если вы всё же решились размещать оборудование в собственной серверной, то следует учесть, полное энергопотребление вашего ЦОДа (серверной) — это энергопотребление ИТ-оборудования плюс потребление всего того, что поддерживает его работу, а именно:

    • систем электропитания, в том числе ИБП, распределительных устройств, генераторов, батарей; сюда же входят потери при распределении внешнего питания к ИТ-оборудованию;
    • компонентов систем охлаждения: чиллеров, градирен, насосов, вентиляционных установок и кондиционеров машинных залов, увлажнителей и т.п.;
    • других нагрузок, например, освещения ЦОДа.

    Для определения энергоэффективности в отрасли принято использовать показатель PUE. Параметр PUE (Power Usage Effectiveness) определяется как отношение энергопотребностей ИТ-инфраструктуры ко всей энергии, поступающей в дата-центр. Идеальное значение PUE равно единице, в этом случае вся используемая площадкой энергия идет на поддержку работы серверов. На практике такая ситуация невозможна, минимальные значения PUE достигают около 1,1-1,15, организация работы с использованием «самых лучших методов» дает в среднем 1,6, а по миру в среднем показатель PUE для дата-центров TIER III составляет 1,98.


    Источник: APC by Schneider Electric, 2010

    Таким образом если номинальная мощность вашего ИТ-оборудования 4 кВт, то при PUE, равном 2, вам потребуется 8 кВт*ч. Если серверная работает круглосуточно, за месяц выйдет около 5800 кВт, что по тарифу 5 рублей за кВт даст затраты на 29000 рублей. Из этого становится понятно, что в цене размещения в коммерческом дата-центре значительную часть затрат занимает электроэнергия, а прочие расходы распределены на многочисленных арендаторов, которые платят меньше, чем если бы реализовывали такие условия на предприятии локально.

    Мы закрепляем расходы 40 000 рублей в месяц на размещение оборудования в коммерческом дата-центре как экономически оптимальный выбор и в дальнейшем будем использовать для расчетов только этот вариант.

    Расходы на программное обеспечение


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

    • сокращение капитальных и эксплуатационных расходов;
    • минимизация или исключение простоев;
    • повышение скорости реагирования, адаптивности и общей эффективности работы ИТ-персонала;
    • ускорение инициализации приложений и ресурсов;
    • обеспечение непрерывности бизнеса и аварийного восстановления;
    • упрощение управления ЦОД;
    • создание полностью программного ЦОД.

    ИТ-отделы сталкиваются с ограничениями современных серверов x86, которые предназначены для одновременного выполнения только одной операционной системы и одного приложения. В результате даже в небольших центрах обработки данных приходится развертывать большое число серверов, загрузка каждого из которых составляет всего лишь 5–15%. Это неэффективно с любой точки зрения [6].

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

    Можно ли использовать бесплатные платформы виртуализации?

    В случае, если вам НЕ требуется массовое развертывание виртуальных серверов в организации, постоянный контроль производительности физических серверов при изменяющейся нагрузке и высокая степень их доступности, вы можете использовать виртуальные машины на основе бесплатных платформ для поддержания внутренних серверов организации [7]. При увеличении числа виртуальных серверов и высокой степени их консолидации на физических платформах требуется применение мощных средств управления и обслуживания виртуальной инфраструктуры. В зависимости от того, необходимо ли вам использовать различные системы и сети хранения данных, например, Storage Area Network (SAN), средства резервного копирования и восстановления после сбоев и «живую» миграцию запущенных виртуальных машин на другое оборудование, вам может не хватить возможностей бесплатных платформ виртуализации, однако, надо отметить, что и бесплатные платформы постоянно обновляются и приобретают новые функции, что расширяет сферу их использования.

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

    Таким образом, мы подходим к выводу о том, что для корпоративного сценария использования, например, ERP системы, нам потребуется платное программное обеспечение виртуализации с расширенным функционалом. Лидирующие позиции на рынке занимаем VMware. Все компании из списка Fortune 500 выбирают инфраструктурную платформу VMware, которая помогла заказчикам сэкономить десятки миллиардов долларов.

    Важным фактором в выборе программной платформы VMware является самая низкая совокупная стоимость владения по сравнению с решениями конкурентов. Вы можете самостоятельно воспользоваться калькуляторами совокупной стоимости владения и окупаемости инвестиций для сравнения с альтернативами, такими как решения от Microsoft и традиционная ИТ-инфраструктура [8].

    Так как изначально мы решили, что будем рассматривать два сценария использования, то для кейса со спортивным порталом, условимся, что будут использоваться бесплатные, open-source программные решения, а в случае с ERP — лицензионное ПО от VMware.



    Итого за ПО виртуализации — 1,2 млн. рублей. Ежегодные расходы на техническую поддержку и доступ к обновлению продуктов — 334 тыс. рублей.

    Добавим к этому лицензию на ПО для СХД среднего уровня — 100 тыс. рублей.

    Расходы на оплату труда персонала


    В то время, как фактические расходы на персонал для поддержки стабильной работы ИТ-инфраструктуры обычно состоят из оплаты труда нескольких разных людей, для простоты мы воспользуемся простым соотношением между количеством серверов и количеством человек, которое вывела компания AWS для использования в своих моделях затрат. Назовем это коэффициентом «server-to-admin».

    Основываясь на обсуждениях с клиентами, AWS обнаружили, что соотношение 50 к 1 представляет собой хорошее среднее значение, полученное из диапазона, характерного для множества компаний. Мы рекомендуем скорректировать это допущение на основе ваших собственных исследований и опыта и включать в расходы на персонал всех людей, занимающихся созданием и управлением вашим физическим центром обработки данных, а не только людей, которые устанавливают и администрируют серверы. Фактическое соотношение между людьми и серверами может сильно варьироваться, поскольку оно зависит от ряда факторов, таких как сложность автоматизации, используемые инструменты, выбор в пользу виртуализованной или не виртуализированной среды.

    Так как мы говорим о некотором абстрактном сотруднике, который будет иметь разную специализацию, соответствующую текущим задачам, мы воспользуемся медианной месячной зарплатой ИТ-специалиста за 1-ое полугодие 2018 года из отчета сервиса «Мой круг» [9].

    Согласно опросу, она составляет 90 000 рублей на человека после вычета всех налогов и сборов. Добавив еще 50% на выплаты в ПФР, ФОМС, ФСС и НДФЛ, получаем 135 000 рублей. Это затраты на одного ИТ-специалиста, который на 100% загружен работой с ИТ-инфраструктурой, создание которой мы описываем в нашем кейсе.

    Так как у нас 4 сервера и 1 СХД, применив «server-to-admin», равный 50 к 1, получаем около 10% затрат рабочего времени одного «универсального» сотрудника или 13,5 тыс. рублей затрат в месяц.

    Общие затраты на собственную инфраструктуру


    Capex (capital expense или capital expenditure) означают капитальные затраты или расходы. Это затраты, как правило, разовые (нерегулярные), направляемые компанией на покупку внеоборотных активов, их модернизацию и реконструкцию.



    Opex (англ. operating expense, operating expenditure — операционные издержки) — затраты, которые несет компания в процессе текущей деятельности для обеспечения функционирования. Такие расходы также называют затратами текущего периода.



    Итоговый TCO такой инфраструктуры составит 7 331 498 рубля за 3 года, и 9 884 214 рублей за 5 лет.



    Таким образом, первоначальные инвестиции в ПО и оборудование в перспективе 5 лет возрастают более чем в 2 раза. Сами по себе 4,8 миллионы необходимые для запуска этой инфраструктуры также содержат в себе риски.

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

    Во-вторых, стоимость денег. Зачастую такие проекты реализуются с привлечением кредитных средств. Получив кредит на 4 млн. рублей с процентной ставкой около минимального порога для юр. лиц в 12% годовых, сумма процентов за 3 года составит 783 тыс. рублей.

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

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

    Раcсчитываем TCO облака


    Так как мы не можем говорить о расходах на облако, не выбрав конкретного провайдера, делать анализ TCO мы будем на своем собственном примере.

    Корпоративный облачный провайдер Cloud4Y с момента основания в 2009 году ориентирован на потребности и высокие требования бизнеса к IT-услугам. Мы предлагаем программно-конфигурируемые дата-центры (vDC) на базе кластерных решений VMware vSphere с управлением посредством портала самообслуживания VMware vCloud Director.

    Помимо модели IaaS (инфраструктура как услуга), мы разработали и успешно предоставляем клиентам множество актуальных и популярных SaaS-продуктов (1С в облаке, удаленные рабочие столы, корпоративная почта, антиспам и многое другое).

    Используемый стек технологий VMware (vSphere, NSX, vCloud Director), надежное оборудование (блейд-серверы HP, all-flash СХД, коммутаторы Cisco и Juniper), расположенное в сети безопасных дата-центров TIER 3, объединенных оптическим кольцом высокой доступности с дублированием каналов связи обеспечивают должное качество услуг и отказоустойчивость необходимые для Enterprise-клиентов.


    Cloud4Y предусмотрено полное аппаратное резервирование серверного и сетевого оборудования. Резервное копирование осуществляется в географически удаленный ЦОД. По умолчанию реализованы кластерные опции VMware: «живая миграция» vMotion, автоматический перенос виртуальной машины на резервный хост в случае сбоя VMware HA (High availability), балансировка нагрузки между хостами VMware DRS.

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

    Техническая поддержка оказывается в режиме 24*7*365. Саппорт разделён на три линии:

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

    Мы видим, что все компоненты облака Cloud4Y спроектированы для обеспечения максимального уровня бесперебойности работы. Это позволяет говорить об общем ожидаемом уровне доступности системы 99,982% в год. Ни один элемент системы, будь то сеть, оборудование, площадка размещения или платформа виртуализации, не является слабым звеном.

    Уровень доступности 99,982% выше, чем запланированный нами минимальный уровень. Итак, перейдем к расчету TCO в облаке и узнаем сможем ли мы получить услуги без премии за повышенную отказоустойчивость.

    Альтернативной по номиналу конфигурацией в облаке будет 32 vCPU, 256 Gb RAM и 11 Tb Medium SAS (4400 IOPS). При расчете на калькуляторе на сайте мы получаем 250 824 рублей в месяц и предложение скидки. В зависимости от проекта скидка будет отличаться, но запланируем возможную скидку на уровне 20%, что в итоге даст нам 2 407 910 рублей в год, 7,22 млн. за 3 года и 12 млн. рублей за 5 лет.

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

    Резервирование


    Во-первых, аппаратное резервирование уже предусмотрено провайдером, в случае сбоя вам будет выделен другой хост из пула ресурсов провайдера. Значит альтернативной конфигурацией по мощности будет 24 vCPU, 196 Gb RAM и 1 Tb Medium SAS и 10 Tb Low. Получаем уже 187 793 рублей в месяц или 150 234 руб. с учетом скидки.

    С учетом этой корректировки мы уже выходим на совокупную стоимость ниже, чем у собственной архитектуры. Мы говорили о 7,3 млн. рублей за 3 года, и 9,9 млн. рублей за 5 лет для собственного «железа». На данном этапе облако уже обходится дешевле — 5,4 и 9 млн. рублей соответственно.

    Эластичность


    Важным преимуществом облачных вычислений является эластичность (rapid elasticity). Ресурсы могут быть оперативно выделены и освобождены, в некоторых случаях автоматически, для быстрого масштабирования соразмерно со спросом. Для потребителя возможности предоставления ресурсов видятся как неограниченные, то есть они могут быть присвоены в любом количестве и в любое время.

    Другими словами, если вам нужно 30 CPU, то вы просто арендуете 30 CPU в облаке. Но, если вы строите собственные ресурсы, то вы определённо не будете создавать именно 30. Представьте, что вы ИТ-директор спортивного веб-портал, и готовите вычислительные мощности для прохождения Чемпионата мира по футболу. В этом случае вы должны быть готовы к пику посещений в этот период, а ключевой вопрос для вас  —  каких именно ресурсов будет достаточно. Если их запланировать слишком мало, то в период крупных спортивных событий их не хватит, а если слишком много, то они будут простаивать остальную часть времени.

    В начале мы говорили о том, что рассмотрим два шаблона использования. В случае с ERP системой мы будем повышать объем использованных ресурсов с 2/3 в первые три года, до полной утилизации (полезной загрузки) в течении 4 и 5 года. Для ресурсов спортивного портала мы предусмотрим два пика почти 100%-загрузки в год длительностью 1 месяц каждый, в остальное время ресурсы будут использоваться только на 40%.

    image

    Именно высокая утилизация ресурсов и эффективное управление позволяет облачным провайдерам зарабатывать на своем деле. Как это поможет сэкономить арендаторам?

    Приступим к расчетам.

    ERP-сценарий: 2/3 утилизации ресурсов (121 тыс. руб/мес.) в первые три года обойдутся в 4,356 млн. рублей, а все 5 лет с учетом роста — 7,961 млн. рублей.

    Спортивный портал: 1/6 утилизации до 100% от максимального количества ресурсов, и 5/6 — 40% утилизации. Ресурсы СХД — рост от 40% до 90% за 5 лет.

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

    image

    Используя ресурсы по мере необходимости, можно сократить затраты до 2,494 млн. руб. за три года и 4,543 млн. руб. за 5 лет.

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



    Облако для сценария корпоративного использования по нашим расчетам обходится дешевле на 1,9 млн рублей или 19,5% дешевле за 5 лет и 40,5% дешевле в перспективе 3 лет.

    Мы добавили варианты с использованием бесплатного программного обеспечение для виртуализации и с арендой физических серверов в ЦОДе со своей лицензией, но даже они проигрывают облаку на отрезке 3 лет. При сравнении 5-летнего TCO эти варианты оказываются «выгоднее», но они предполагают снижение управляемости, отказоустойчивости и гибкости. Такие варианты слабо применимы для корпоративного ИТ, в сценарии же использования для спортивного портала эти варианты проигрывают облаку и в ТСО-5лет.

    Стоимость денег


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

    • о прибыли от 1,7 млн. рублей от свободного денежного потока (разница между затратами на on-premise и cloud помесячно) и сэкономленных 1,9 млн. в течение 5 лет в сценарии с ERP
    • и 2,5 млн. «неупущенной» прибыли для спортивного портала плюс сэкономленные 5,3 млн. рублей.

    Pay as you go


    Cloud4Y предоставляет модель оплаты «Pay as you go» по каждому типу ресурса по отдельности. Такой подход дает возможность оплачивать ресурсы по факту потребления. Используем сегодня ровно столько ядер и оперативной памяти, сколько нужно. Стоит отметить, что во всех случаях, плата за CPU и RAM берётся только за «включенное» время, в момент, когда вы не пользуетесь виртуальной машиной — плата не взимается. А вот за хранилище придётся платить в независимости от того, включена машина или выключена — плата берётся до момента, пока на диске есть данные, если диск чистый — плата не взимается.

    На сайте вы можете найти калькулятор стоимости услуг, но стоит отметить, что он работает на основе предположения использования ВМ в режиме 24х7х30. Используя VM в режиме 12х5х30, стоимость услуги для вас может быть ниже более чем на 50-60%. Такой шаблон утилизации ресурсов характерен, например, для инфраструктуры виртуальных удаленных рабочих столов или «облачного офиса». Когда сотрудники организации не работают, виртуальные машины с их рабочими столами отключаются, и начинается экономия. Мы не рассматривали такой сценарий использования в сравнении TCO, но логично и проверено на практике, что облако обходит другие альтернативы и в этом кейсе.

    Выводы


    image

    На графике ясно видно, что в течение всего 5-летнего срока эксплуатации ИТ-инфраструктуры облако Cloud4Y выигрывает у покупки собственного «железа». За пределами этого периода, скорее всего, серверы морально устареют и необходимо будет приобрести новые. За обновление оборудования в облаке отвечает также сам провайдер. Таким образом, рассмотрение более продолжительного периода не изменит ситуацию с экономической целесообразностью облака.

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

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

    Источники
    1. Оптимизация расходов на IT // Интернет-проект «Корпоративный менеджмент». URL: www.cfin.ru/itm/tco.shtml (дата обращения 20.09.2018)
    2. Официальный сайт Uptime Institute. URL: ru.uptimeinstitute.com (дата обращения: 19.09.2018)
    3. Мифы и заблуждения относительно Tier-системы сертификации Uptime Institute // Сайт Cloud4Y. URL: www.cloud4y.ru/about/news/Myths-and-Misconceptions-Regarding-the-Uptime-Institute%E2%80%99s-Tier-Certification-System (дата обращения: 19.09.2018)
    4. Сайт Hewlett Packard Enterprise Support Services Central. URL: ssc.hpe.com/portal/site/ssc/?action=determineNodeContents&nodeId=30749 (дата обращения: 24.09.2018, выбранная длительность — 2 года)
    5. «Оценка совокупной стоимости владения центром обработки данных». URL: bijournal.hse.ru/data/2016/08/11/1118257058/%D0%9F%D0%B8%D1%80%D0%BE%D0%B3%D0%BE%D0%B2%D0%B0%20%D0%93%D1%80%D0%B5%D0%BA%D1%83%D0%BB%20%D0%9F%D0%BE%D0%BA%D0%BB%D0%BE%D0%BD%D0%BE%D0%B2%20%D0%A0%D0%A3%D0%A1.pdf (дата обращения: 24.09.2018)
    6. Принципы виртуализации // Официальный сайт VMware. URL: www.vmware.com/ru/solutions/virtualization.html (дата обращения: 25.09.2018)
    7. Бесплатные серверные платформы виртуализации. URL: www.ixbt.com/cm/virtualization-servers-free.shtml (дата обращения: 25.09.2018)
    8. VMware TCO Comparison Calculator. URL: tco.vmware.com/tcocalculator (дата обращения: 24.09.2018)
    9. Зарплаты ИТ-специалистов на середину 2018 года // Блог сервиса «Мой круг» на Хабр URL: habr.com/company/moikrug/blog/420391 (дата обращения: 20.09.2018)


    Ссылка на бесплатную загрузку White Paper: Расчет TCO «Облако vs Покупка Серверов» (.pdf)

    Cloud4Y

    79,00

    #1 Корпоративный облачный провайдер

    Поделиться публикацией
    Комментарии 55
      +3
      Вы говорите о владении инфраструктурой, но обходите вопрос об аренде того же по мощности железа в ДЦ, с развертыванием на нем своей инфраструктуры так, как хочется самим, а не так, как облачный провайдер нарежет.

      Не буду много писать, но аренда железа получается куда интереснее: во-первых, раз в 2-3 года за те же деньги можно просить ДЦ выдать железки очередного нового поколения (и ДЦ будет не в обиде — они старое, полученное из аренды, за копейку следующим клиентам сдадут), во-вторых, сумма за железо не висит на балансе, а списывается ежемесячно по совсем другим статьям. В-третьих, железо здесь «свое», его не нужно делить с другими клиентами.

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

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

      Хотя, конечно, допустимый даунтайм много значит. Если мы не можем себе разрешить «лежать» более 5 минут в год, то и IAAS нужен того уровня, чтобы эту цифру держал — а даже ДЦ такого класса в России мало (а ведь IAAS — это ДЦ, а уже поверх него надежность самого провайдера), а если час-два в год допустимо (что, как раз, в Tier3 вписывается), о и со своей инфраструктурой можно прожить неплохо.

      А что исходно TCO придумывалось коммерческой организацией для оправдания цен других коммерческих организаций — это как бы намекало поначалу, с каким прицелом метрики придумывались.
        0
        del.
          0
          Вариант аренда «железа» + ПО VMware мы добавили в сравнение. В таком случае облако для корп.нужд эффективнее в течение 3 лет, а для спортивного портала и на 5 лет. Вариант аренда серверов и опен сорс ПО потребует либо очень высокой квалификации персонала (зарплата «съест» экономию), либо не будет соответствовать по отказоустойчивости, управляемости и гибкости
            +3
            Так ведь мысль, что «если IAAS, то рукастые админы не нужны» — это порочная мысль. Во-первых, меньше рукастых админов — это падение индустрии, а не ее развитие. Во-вторых, IAAS продает не то. что нужно людям, а то, что могут и хотят продавать (и нарезают так, как удобно биллинговать).

            А если в проект все же заложить руки на кого-то рукастого, то на з/п уже экономии нет, на железе — хм… Имея сервер, я сразу могу полностью его ресурсы использовать, а в облаке вся выгода будет, если только я арендую только-только сколько нужно под проект. Взял еще виртуалку-другую для теста — и стало уже дороже (а на «своем» сервере нарезать еще машинку куда легче за те же деньги).
              +1
              то на з/п уже экономии нет, на железе — хм…

              У меня сейчас 70% времени уходит на всякую ерунду, к серверам отношения не имеющую. 30 оставшихся можно было бы сократить до 10, если бы сервера были однотипными. Т.е. я могу, условно, поддерживать в 10 раз больше серверов, чем у меня есть, если просто поменять организацию труда (изолировать меня от пользователей и сократить количество сервисов). При этом моя квалификация останется той же, да и ЗП скорее всего тоже.

              Еще можно вспомнить про всякие фенечки вроде ansible, ovirt, docker и т.д., которые могут увеличить производительность моего труда еще на пару порядков, но которые не применимы к масштабу бизнеса текущего работодателя (глупо рулить ансиблом виртуалками в группах по 1-2). И тогда на фоне стоимости харда и софта з/п вообще потеряется.
              Во-первых, меньше рукастых админов — это падение индустрии

              Когда-то во Франции церковь ввела предка копирайта, потому что не хотела терять рабочие места (на копировании книг). Сокращение численности работников не всегда вредит индустрии. А вот реакция общества на это может быть неадекватной.
              Во-вторых, IAAS продает не то. что нужно людям

              И потому до сих пор большинство из нас работает.
                0
                И потому до сих пор большинство из нас работает.


                Если брать любую профессию, то, по мере автоматизации, мы видим падение необходимости в столь большом числе «ручных» мастеров в ней. Однако потом приходит «вторая волна» — да, отвалились подмастерья, но будущим-то мастерам где-то надо «набивать руку»? Даже сегодня, толкового эникейщика найдите-ка, не говоря о хорошем спеце, а что станет, если число «админов» уменьшится раз в 100? Тем же облакам где искать разумных и опытных спецов, которые всё это облако будут поддерживать?

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

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

                  Что будет, когда вымрут мастадонты, которые умели паять компьютеры из микросхем в гараже? Современные SoC вымрут?
                  Просто число специалистов сократится, а призвание превратится в профессию. Будут готовить 3,5 сис. администратора в год в ВУЗах сразу со специализацией на виртуализацию, или веб, или железо и т.п… Как сейчас происходит у проектировщиков.
                  Будет ли с этого толк в ИТ — думаю, нет.

                  Ну нас, как обычно, об этом не спросят. Введут очередной закон, который обяжет содержать it-шника в штате, как сейчас обязательно содержать бухгалтеров и юристов. Лет через 50 возможно само отвалится или превратится в невероятную химеру (как копирайт).
                  Ну а самое главное — облако нужно не всем.

                  По моим наблюдениям, сейчас все стремятся в облако. Просто иногда не в амазон/гугл, а в частное облако.
                  «как уйти с публичного облака на свои сервера»

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

                  Мне этот процесс тоже не нравится. Но он объективен, увы.
          +1
          Очень хочется продать свое облако, ну прям очень. Столько много написали, видимо, что бы люди сдались, и не стали читать, а сразу к итогам прокрутили. Причем итоги ясны с самого начала, еще начала статьи. Спорить по каждому пункту с вами — просто бессмысленно, вы будете топить свою тему до конца — это ваша работа. Только тот кто в теме — сразу увидит, что и колокейшен стоит в 2 раза дешевле, и софт, и поддержка разная бывает, и не всегда нужна в принципе.

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

            Следующим пунктом идет обоснование определения уровня отказоустойчивости всей ИТ-системы как ключевой характеристики «to compare apples to apples». Всегда можно найти что-то подешевле, но уже не то.
              0
              Натянули таки сову на глобус… Давайте, допустим… и в конце-концов получили нужные цифры. С лицензиями тоже все очень весело. Столько допущений во всей статье. Потребление электричества посчитано абы-как.
                0
                Честно говоря, не натягивали. У облака есть преимущества, мы берем основные и считаем их экономию. Уже на этом этапе получается приличный задел по экономии. Далее мы говорим, что опционально можно сэкономить еще и на том-то и том-то. Такой расчет «с гаком» делается как раз, чтобы обнулить замечания на допущения в якобы выгодную для нас сторону. Вот так это работает.
                0
                Всегда можно найти что-то подешевле, но уже не то.

                Например, кластер Nutanix будет дешевле, быстрее (кстати, во сколько раз вырастет цена вашего сториджа при требовании 20k IOPS от «быстрого тира»?) и надёжнее предлагаемой техники HPE.
              0
              «ИТ-отделы сталкиваются с ограничениями современных серверов x86, которые предназначены для одновременного выполнения только одной операционной системы и одного приложения. В результате даже в небольших центрах обработки данных приходится развертывать большое число серверов, загрузка каждого из которых составляет всего лишь 5–15%. Это неэффективно с любой точки зрения»

              Это что за бред? Агитка VMware, вы под ней расписываетесь?
              Вы серьёзно что на x86 можно запустить только одну залачу, а также на НЕ x86 можно запускать несколько операционных систем одновременно, не в режиме виртуализации?

              Зачем у вас 4 сервера с 1 процессором ( кстати какой версии — от этого цены в 1,5 раза различаются) вместо 2 сревреров с 2 процами?
              Зачем коммутатор — если он не нужен.

              Итог — нам достаточно 3 юнита.

              Железо через 5 лет не сгорает а имеет остаточную стоимость.

              Стоимость ваших услуг за 5 лет может измениться, и точно не в сторону уменьшения.
                0
                Стоимость ваших услуг за 5 лет может измениться, и точно не в сторону уменьшения.
                Откуда такая точность? Вот тут вывод совсем другой и основан на фактах.

                О том, что можно получить сопоставимую вычислительную мощность дешевле, никто не спорит. Мы говорим об уровне отказоустойчивости всей ИТ-системы как ключевой характеристики «to compare apples to apples».

                Железо через 5 лет не сгорает а имеет остаточную стоимость.
                Насколько велика остаточная стоимость железа и легко ли его продать по вашему опыту? Облако обходит равные по отказоустойчивости альтернативы с большим заделом, поэтому мы не вносили в итоговый расчет многих опциональных выгод: стоимость капитала, цена ошибки, премия за эластичность, pay as you go — всё это лишь обозначено, а в расчете только обязательные с нашей точки зрения расходы.
                  +2
                  «Откуда такая точность? Вот тут вывод совсем другой и основан на фактах»
                  Мы не в Америке живем — прошу расчет цен ВАШЕЙ компании, с 2010 года.

                  «Насколько велика остаточная стоимость железа и легко ли его продать по вашему опыту»
                  20%-30% от изначальной стоимости, продать без проблем.

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

                +1
                Выводы, конечно, за уши притянуты.

                Cloud vs On premise
                В общем случае есть только два главных фактора.
                Эластичность — если утилизация скачет, Cloud выигрывает.
                И масштаб — 1 сервер? Cloud. 1000 серверов? On premise.

                И да, есть другие факторы, которые в определенных контекстах становятся главными.
                И да, есть промежуточные решения между Cloud и On Premise.
                  0

                  Не-не-не.


                  Мы, даже с нашими достаточно небольшими потребностями, со вздохом сползли с aws на арендованное железо. Причина, если разобраться, простая: пока всё работает, все работает. Как только что-то не работает, концов не найдешь.


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

                    0
                    Вот! Отличная формулировка. Концов не найдёшь. Но наслушаешься/начитаешься о том, как ты для них важен, как тебя благодарят за длительное ожидание, а потом в итоге тыкнут носом в какой-нибудь пункт EULA, где написано, что никто никому ничего не гарантировал.
                    +1

                    Вот не совсем заслуженно накинулись. Да в статье есть углы, которые обошли.


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


                    И, да, пока что на горизонте я для себя IaaS пока не вижу разумным :)

                      +1
                      Конечно ребята старались — это их работа. Примерно такая же, как работа таксиста у вокзала, который всех подряд спрашивает «Такси не дорого надо» а по факту, за 3 стоимости везет.
                      Вот тут один в один. Нам впаривают услугу которая не стоит своих денег, и рассчитана на незнание клиента реального рыночного расклада.
                        –1
                        Пользователь очень старается все опровергнуть. Тут вопрос — это его работа? Откуда столько мотивации
                          0
                          Я даже представить не могу, какая же может быть моя работа, в вашем предположении.
                          0

                          https://habr.com/company/activecloudru/blog/415483/#comment_18853179


                          Просто для общей картины.


                          Лично мне облака как сервис не нравятся, комментарии по этому поводу можно найти далеко не в единственном числе.


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


                          Но в целом статья заметно выделяется на общем уровне принятия решений и оценки необходимости облаков. И выделяется в лучшую сторону

                            –1

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

                              0
                              1. Интернет образует глобальное информационное пространство
                              2. Хабр в Интернет для поисковиков выше относительно «нехабр»
                              3. Лонгрид выйдет высоко в выдачу поисковика, даже если тут ЦА не та.

                              Тут относительно хорошо и ЦА частично всё же та. А где это «частично» лучше по вашему мнению?
                                0

                                Я готов к дискуссии по поводу светлого и в массы. Но вы, по всей видимости, во главу ставите SEO, а не истину или хотя бы собственный продукт.


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


                                Собрать feedback, улучшить продукт, скорректировать контент…

                                  0
                                  Если взять за основу определение Клода Шенона
                                  «Истина — это основа для множества разнообразных решений множества разных задач», говорить, что в статье именно эта Истина нельзя.

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

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

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

                                    Слишком толсто

                        0
                        Для малого бизнеса риски по персоналу высоки (незаменимый админ). Для крупного бизнеса все портит «прожорливый» 2-ой и 3-ий уровень менеджмента (руководители руководителей руководителей админов). Но вот для среднего бизнеса, несколько взаимозаменяемых «бойцов» во главе с толковым спецом, а не просто «эффективным менеджером», творят чудеса серверной инфраструктуры, недоступные по стоимости в терминах TCO никаким облакам. Устаревающее оборудование переводится в среды тестирования и разработки и эксплуатируется там до физической смерти, а виртуализация — это просто магия эффективного использования ресурсов и надежности.
                          0
                          Работал когда-то в такой команде в среднем бизнесе. Это было наиболее интересное время в моей профессиональной жизни. И мы даже не считали, что делаем что-то эдакое. Просто было очень увлекательно. Действительно, и старьё в тест переводили, было дело.
                          0
                          переезд на местечковые облака — безумие. вон рядышком 1Cloud левого пользователя ставила, а ушлые крякеры биткоины на машинах клиентов маинили. с гуглом тоже не все гладко, куча жалоб, что гугл сначала банит аккаунт, потом разбирается, что там за нагрузка. сначала бизнес должен определиться, уверен ли он что хочет в критический момент убеждать Равшана с зп 8к рублей, что он ошибся и зря отключил сервера. и только потом смотреть на какие-то детали ТСО, не забыв приплюсовать майнинг биткоинов.
                          Cloud4Y, я верно понимаю что расчеты без SLA и вы в принципе ничего похожего на SLA не подписываете?
                            +1
                            ушлые крякеры биткоины на машинах клиентов маинили

                            Из нашего типового SLA

                            Показатели производительности CPU и RAM системы
                            Количество MIPS на одно vCPU — Не менее 2900 (программным обеспечением 7 ZIP/12MB (запускается из ОС виртуальной машины)
                            RAM Swaped процент от сконфигурированной памяти VM — 0% (Система мониторинга Исполнителя (vCenter))
                            Всё 100% выделено и проверяется.

                            Подписываем SLA, ожидаемая минимальная доступность 99,982%
                            Ответственность Исполнителя — 1% от месячной стоимости за 1 час (берется общая месячная стоимость услуги за полный календарный месяц, предшествующий данному), но не более 100% месячной стоимости услуги
                              0
                              ну вот в ситуации аля 1Cloud, что-то ваш SLA гарантирует? вот вижу я что на моем сервере левый юзер, нейпойми откуда. вижу, что жрет он ресурсы, а я плачу. как быстро вы на такое отреагировать по SLA обязаны? обязаны ли вообще? ресурсы то доступны, просто по вашей вине ресурсы кто-то другой кушает.
                                0
                                надо разбираться по чьей вине появился «левый юзер», потом по SLA, ГК, УК и так далее.
                                  0
                                  вот на это разобраться есть ли SLA?
                                0
                                Тут заранее отвечу всем, кто считает, что 1% в час это слабая мотивация. В месяце более 700 часов. А откуда провайдер берет деньги? Правильно зарабатывает по 1/700 в час. А теряет в случае сбоя по 1/100, то есть в 7 раз быстрее. Теряет не прибыль а доход, а прибыль в 50-70 раз быстрее, чем зарабатывает. Вот поэтому провайдер очень хочет, чтобы без сбоев. Или быстро починить.

                                А еще ущерб репутации и потеря клиентов, которые могут быть очень большими — особенность облачного провайдера.
                                  0
                                  1% в час — надо сравнивать со стоимостью простоя, который у вас в статье написан.
                                  Тогда, как то не впечатляюще выглядит.
                                    0
                                    Хороший бизнес не тот, который хорошо «тушит пожары», а тот, в котором создали систему, в которой минимальная возможность пожара.

                                    Клиенты выбирают уровень отказоустойчивости для того, чтобы сбоев было минимум, а не для того, чтобы зарабатывать на сбоях. «Наш провайдер упал — Бинго! Все в отпуск на месяц».
                              0
                              Любую методику расчета чего-либо можно мягко направлять в нужное русло. Как пример — расчет IQ.
                              Придумали методику, вдруг выяснилось — чернокожие как-то близко подобрались к белым — поправили. Вдруг получилось, что женщины почти сравнялись с мужчинами — опять поправили и так несколько раз.
                                0
                                Никто не обратил внимание на очень важный момент — как только мы выносим критически важную для бизнеса инфраструктуру в сторону от того места, где эта инфраструктура зарабатывает деньги, то мы мгновенно получаем проблемы с каналами связи. Пропускная способность, задержки, безопасность, CCNE в штате, вот это всё…
                                Проблема характерна для малых предприятий, где всё централизовано и нехарактерна для корпораций, где по этим граблям уже прошлись, причём неоднократно и разные люди.
                                  +1
                                  Маркетинг-маркетинг-маркетинг и неичего кроме. А по факту предлагаете заранее подготовленные шаблонные проекты. Шаг влево-шаг вправо по желанию заказчика загоняет в жесточайший диссонанс ваших специалистов, менеджер после трех-четырех прозвонов вообще самоустранился.

                                  А по ценам и тарифным сеткам я вообще молчу, Dataline не совсем «честный» но всё же намеки на pays-you-go наблюдаются, Mail.ru уже тарифицирует по «честному» pays-you-go без стоимости «резервирования», да даже Биллайн уже «вчестную» работают. А вы что?
                                  При том что цена аренды ни чуть не ниже чем у конкурентов.
                                  Так что сорри, на фоне вышеозначенных компаний вы «не торт».
                                    0
                                    А что Титов? Отпишитесь, лучше в личные сообщения, какой менеджер, какой проект, почему вы решили, что самоустранился, а не взял время на согласование с тех. отделом? У него есть ваши контакты? Когда это произошло?

                                    «Наш pays-you-go» описан в статье и вполне «торт»
                                      0
                                      А по факту предлагаете заранее подготовленные шаблонные проекты.
                                      Тут совсем не понял. У нас вы можете развернуть свой vDC (программно-конфигурируемый дата-центр) через портал самообслуживания vCloud Director 9.0. С помощью встроенной библиотеки VMware NSX можно настроить программно-определяемые сети нужной топологии между ВМ или создать гибридное облако. Да, при создании ВМ есть шаблоны, но необходимости использовать только их нет.
                                      0

                                      Ох как я обожаю такие статьи! Это виртуозное жонглирование фактами и мастерская подмена понятий!!! Прям аплодирую стоя!
                                      Что есть хорошего в статье:


                                      1. Формулы расчета

                                      О чем, по моему мнению умолчали:


                                      1. ERP на 350 пользователей может вполне себе предъявлять такие требования что у облачного провайдера просто не будет таких мощностей (типа под SAP)
                                      2. "Шумные соседи" — молчком
                                      3. Есть ERP которые уже сразу же поставляются как Software as Service — возможно это более правильный выход
                                      4. Популярный спортивный канал — это что? 3 статичные странички или мегапортал с преферансом и профурсетками? подходы и требования кардинально разные
                                      5. А почему сетевухи 10G, еще и 2? А это реально надо?
                                      6. Купив 4 сервера (опять же без моделей проца) можно напихать дисков и построить SDS — тогда не нужен будет сторадж
                                      7. 2 коммутатора на 10G за 200к? Вы DLink считали?
                                      8. Конфигурация рейдов в сторадже — ну ладно, это отдельная тема
                                      9. СХД вы посчитали, а SAN-свитчи? А если без них — то как? iSCSI? тоже отдельная тема.
                                      10. Гарантию от вендора при покупке можно взять сразу же на 5 лет — будет дешевле
                                      11. ЦОД. 40к — это стойка. А мы займет 6-8 юнитов. Почти вся стойка простаивает. Плюс сейчас цоды сичтают электричество по затратам — в этом случае будет ± 30к
                                      12. Экономическая целесообразность VMWare реально проявляется если у тебя или все на *nix системах, или когда у тебя очень специфические задачи/аплаенсы
                                      13. Почему-то для VMware не считается стоимость поддержки за 4 года дополнительно
                                      14. Резервирование предусмотрено и on-premis — серверов то 4 + vmawre с миграцией
                                      15. Нет учета подъема стоимости ваших услуг за 5 лет

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

                                        0
                                        Экономическая целесообразность VMWare реально проявляется если у тебя или все на *nix системах, или когда у тебя очень специфические задачи/аплаенсы

                                        Мне всегда казалось, что VMWare это в большей степени для Windows. Админам Linux как-то проще жить с KVM решениями. Например все драйвера идут из коробки в ванильном ядре и никаких dkms не надо. Да и цена на решение от того же RedHat ниже чем у VMWare, я уж не говорю про бесплатный кейс.

                                        –1
                                        Что вы все цепляетесь к стоимости владения?
                                        Как говорил мой шеф — «Живем здесь и сейчас. Меня интересует только бабло которое я получаю сейчас». 80% всех руководителей рассуждают так же.

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

                                        Минусы облаков:
                                        1) Стоимость большая
                                        2) Риски точно такие же, как и при обычном подходе (даже больше ибо нормальных контор мало)
                                        3) Зависишь от инета провайдера, не все сидят в крутых бизнес центрах
                                        4) Организационные риски(забыли бабла заплатить за аренду облаков)
                                        И зачем это нужно малому и среднему бизнесу?
                                          –1
                                          1) Стоимость большая
                                          Относительно булки хлеба? Расчет TCO выполняется для сравнения альтернатив, анализ показал, что стоимость облаков меньше on-prem.

                                          2) Риски точно такие же, как и при обычном подходе (даже больше ибо нормальных контор мало)
                                          Что такое обычный подход? Частей системы может быть множество, а последствия — разными. Конторы нужны проверять и тестировать.

                                          3) Зависишь от инета провайдера, не все сидят в крутых бизнес центрах
                                          Согласен. В этом случае можно совмещать с Edge computing, оперативные вычисления делать на периферии, централизовано хранить в облаке общие данные разных филиалов и резервные копии.

                                          4) Организационные риски(забыли бабла заплатить за аренду облаков)
                                          Мы и позвоним, и напишем.

                                          И зачем это нужно малому и среднему бизнесу?
                                          Чтобы получить возможности, которые создать тяжело, а сэкономленное время тратить на основной процесс создания добавочной стоимости.
                                            0
                                            1) «Относительно булки хлеба? Расчет TCO выполняется для сравнения альтернатив, анализ показал, что стоимость облаков меньше.»

                                            Ну так анализ показал, что и пенсионный возраст нужно поднять)))

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

                                            А я и не спорю и говорю про мелкий и средний бизнес, коих 90% рынка

                                            3) «Согласен. В этом случае можно совмещать с Edge computing, оперативные вычисления делать на периферии, централизовано хранить в облаке общие данные разных филиалов и резервные копии.»

                                            В этом мире и так много боли и страданий. Зачем мне эти телодвижения?

                                            4) «Мы и позвоним, и напишем.»

                                            Охотно верю


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

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

                                              Систему нельзя кормить людьми. Как сказал Кант: «Относитесь к человеку как к цели и никогда как к средству».


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

                                              В этом мире и так много боли и страданий. Зачем мне эти телодвижения?
                                              Чтобы сократить количество боли и страданий в случае сбоя, повысив отказоустойчивость и скорость восстановления.
                                                0
                                                Зашел на ваш сайт что бы ради интереса просчитать стоимость сервера для 1С удовлетворяющего потребности нашей компании.
                                                Получается:
                                                51 7624тыс один сервер + 7000 тыс/ поддержка
                                                Т.е ~ 59 тыс в месяц. Это 700 тыс в год.
                                                Это что дешево?
                                                Я за 500тыс куплю такой же сервер, который 7-8 лет нормально будет работать. (500/8)/12 = ~ 5тыс в.мес т.е ваше предложение в 10 раз дороже.

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

                                                  –1
                                                  не знаю требуемой спецификации, но вы читали статью? почему вы приравняли стоимость оборудования (1 сервера) к совокупной стоимости владения ИТ-инфраструктуры (ТСО)?
                                                    0
                                                    Я показал только на примере одного сервера, если переносить всю инфраструктуру, то это будет финансовый мрак
                                                      0
                                                      Вы показали только х% (где х<50%) TCO собственного сервера и около 100% TCO облака, а достигнутые уровни отказоустойчивости совсем не взяли в расчет
                                          0
                                          Я тут тоже прикинул навскидку:
                                          Тариф 4ядра по 2,66+8Gb+250ssd+1IP+windows+5Mbts=11 846.74 в мес
                                          Сервер на днс Сервер Dell Precision 3420 SFF [3420-4506]
                                          [LGA1151, 1xIntel Core i7-7700, 3600 МГц x4, 8 Гб, 0.250 Тб, DVD±RW, NV Quadro P1000 4GB, Win10Pro, Small Form Factor, 240Watt 3года гарантии] -113 999руб Кредит онлайн от 11113 руб./мес.
                                          Интернет ростелеком 70Mbts +1IP+yandex 1Tb (бекапить) -820руб/мес
                                          Электричество- 0,25*24*30=180*4руб=720руб/мес
                                          Итого=11113+820+720=12653

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

                                          Да вы скажете что это неспортивно и цены для физиков несравнимы с юриками и надежностью, только если мрет провайдер, то зачастую мрет весь город, а с электричеством UPS и инверторный генератор спасут вполне. Начальный уровень фирм вытягивается так полностью, а крупные сами строят свои цоды.
                                            0
                                            малое количество предприятий среднего бизнеса — проблема рынка облачных провайдеров РФ, крупным иногда нужно гибридное облако и тестовые мощности, малым — возможности для роста, чтобы не быть запертыми в своей ИТ-инфраструктуре.

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

                                          Самое читаемое