TCO. Простыми словами для начинающих технарей

Предисловие

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


Квадрантура. Gartner's Quadrant x86 виртуализации больше нет

Меня периодически спрашивают, почему я не сделал традиционный микс квадрантов по x86 серверной виртуализации в 2017 году.
Ответ прост - Гартнер прекратил выпускать аналитику по этому сегменту рынка, так как по их мнению рынок зрелый, и смысла в этом квадранте нет. Вот ссылка: https://www.gartner.com/doc/3642418/gartner-retires-magic-quadrant-x.
По их словам основное развитие идет на рынках контейнерной виртуализации для разработчиков, и облачных сервисов на базе серверной виртуализации.
Там же предлагается купить за $500 пятистраничный путеводитель по рынку "Market Guide for x86 Server Virtualization Infrastructure".

Так что вот здесь: http://www.veskin.ru/2016/08/gartners-quadrant-x86-2016.html - последняя моя сборка квадрантов.

На что теперь стоит смотреть? Я бы рекоментовал квадрант по IaaS (Magic Quadrant for Cloud Infrastructure as a Service): https://www.gartner.com/doc/reprints?id=1-2G2O5FC&ct=150519.

Облака. Как дёшево уйти с рынка

Один из интересных реальных способов применения облачных технологий.

Риск - дело благородное, но затратное

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

Практически любой современный бизнес требует наличие какой бы то ни было ИТ инфраструктуры. Соответственно, создавая новый сервис вам необходимо вложить средства и в ИТ. Если это обычная закупка инфраструктуры - это, в первую очередь, CapEx (капитальные затраты) на оборудование, ПО, инженерную инфраструктуру, работы по внедрению. И это - OpEx (операционные затраты) на поддержание работы бизнес-сервиса: электричество, вода, стоимость места в помещении, трудозатраты на обслуживание и т.д.
CapEx при закрытии сервиса бизнес вернуть себе не сможет (разве что перепродать по дешёвке неиспользуемое оборудование). И в итоге владельцы останутся у разбитого развернутого ненужного корыта, которое будет, к тому же, потреблять минимальный OpEx даже после выключения оборудования, так как оно занимает место - т.е. стоимость аренды занимаемого помещения и работы по протирки оборудования.

Как минимизировать такие возможные потери? Использовать для сервиса внешнее арендуемое облако.
В этом случае CapEx сильно сокращается:

Магический Квадрант Гартнера. Как его читать

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

Кто такие Гартнер (Gartner)? Это аналитическая и консалтинговая компания, специализирующаяся в сфере ИТ. Исследует рынки, публикует отчеты и консультирует другие компании.

Gartner Magic Quadrant - один из их популярных видов отчетов представленных по изучению того или иного рынка ИТ. 
Этот отчет необходим для оценки и выбора наиболее подходящей для своей инфраструктуры системы. Как правило, предназначен для руководителей в компании, принимающих решение о закупке и внедрении.
Самое главное, что вам нужно знать:
Оцениваются не конечные продукты, как таковые, а поставщики, т.е. компании, которые производят это решение

Вот вам шпаргалка, как правильно прочитать квадрант:

RTO и RPO. часть 5

В прошлой статье серии я рассматривал связь бизнеса (читай – денег) и ИТ сервисов. В этой части хочу сделать шаг в сторону практической реализации того, о чем писал в прошлых частях рассказа про RTO/RPO.
Но сразу оговорюсь, метод, описанный ниже, подойдет лишь для небольших ИТ-инфраструктур.

Список статей:
Часть 1: http://www.veskin.ru/2010/10/rto-rpo.html
Часть 2: http://www.veskin.ru/2017/03/rto-rpo-2.html
Часть 3: http://www.veskin.ru/2017/04/rto-rpo-3.html
Часть 4: http://www.veskin.ru/2017/04/rto-rpo-4.html
Часть 5: http://www.veskin.ru/2017/09/rto-rpo-5.html 

“If you fail to plan, you are planning to fail!”
                                                                  Б.Франклин

Или перефразирую известную песенку:
«Ни минуты простоя,
ни секунды простоя…
лишь бы не было сбоя…»

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

RTO и RPO. часть 4

И снова немного про "бизнес" (вот, думаю, может лучше взять в кавычки слово "немного"?;)).
Почему я пишу в техническом блоге про финансовую сторону, про деньги? Это нужно знать техническим специалистам, если вы не хотите застрять в профессии на одной ступеньке без возможности дальнейшего развития. Как собственного внутреннего развития, так и развития в глазах ваших коллег. Как технического специалиста  вас персонально могут воспринимать по-разному. И если вы будете знать, как ваша деятельность в компании помогает ей двигаться к намеченным финансовым целям, вы повысите понимание деятельности ИТ-службы в глазах ваших коллег. Не умея донести до пользователей внутри компании свою полезность, ИТ превращается в обособленное непонятное подразделение, требующее только расходов на себя. И вы  становитесь такой же затратной единицей в глазах своей компании.


Список статей:
Часть 1: http://www.veskin.ru/2010/10/rto-rpo.html
Часть 2: http://www.veskin.ru/2017/03/rto-rpo-2.html
Часть 3: http://www.veskin.ru/2017/04/rto-rpo-3.html
Часть 4: http://www.veskin.ru/2017/04/rto-rpo-4.html
Часть 5: http://www.veskin.ru/2017/09/rto-rpo-5.html

В прошлый раз я остановился на термине "доступность". Да, доступность - это два-в-одном-и-оба-сразу: доступность данных и доступность сервисов. Бэкап, к примеру, не нужен сам по себе. Это одно из средств обеспечения доступности.

Доступность в свою очередь является частью обеспечения непрерывности бизнеса. Вы наверняка слышали такое понятие.

RTO и RPO. часть 3

Продолжаю серию статей про RTO/RPO.

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

Несколько комментариев к графику:

RTO и RPO. часть 2

К международному дню резервного копирования (или, как еще его называют День Бэкапа).

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

Список статей:
Часть 1: http://www.veskin.ru/2010/10/rto-rpo.html
Часть 2: http://www.veskin.ru/2017/03/rto-rpo-2.html
Часть 3: http://www.veskin.ru/2017/04/rto-rpo-3.html
Часть 4: http://www.veskin.ru/2017/04/rto-rpo-4.html
Часть 5: http://www.veskin.ru/2017/09/rto-rpo-5.html


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