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. Любая информационная система должна обеспечивать (внутренними ли средствами, или сторонними) возможность восстановления своей работы в приемлемый срок.

Veeam Backup for Linux

Вообще-то он называется Veeam Agent for Linux. И вчера вышла в релиз версия 1.0.

Для чего нужны агенты? Где без них никак?

Во-первых, это физические машины. И не совсем виртуализированные: например, pRDM диски у виртуальных машин VMware и т.п.

Во-вторых, ВМ, которые расположены на стороне сервис-провайдера. Чего бы вам не обещал провайдер, но если он сломается - он потеряет ваши данные. И вряд ли будет утешением, если этот провайдер закроется после этого, данные не вернуться: моральная компенсация - не Instant Recovery ;).

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

Почему же агентом? Потому что вам никто из провайдеров не даст доступ к API виртуализации для резервного копирования.


Для кого подходит новый бэкап?

Поддерживаемые системы:

  • ЦП: x86/x64
  • Ядро: 2.6.32 или выше
  • ОС: 32- и 64-разрядные версии следующих операционных систем:
    • Debian 6.x-8.x
    • Ubuntu 10.04-16.10
    • RHEL/CentOS/Oracle Linux 6.x-7.x
    • Fedora 23, 24
    • openSUSE 11.3-13.x, Leap 42.1
    • SLES 11 SP1 – 12
Практически весь необходимый функционал - бесплатный. Кроме:
  1. Поддержка 24x7 - в платных редакциях (Workstation и Server). В бесплатной - стандартная бесплатная поддержка.
  2. Множество исполняемых заданий. Когда нужно копировать в машине - всю систему раз в неделю, пару томов - ежедневно, и несколько папок - раз в час, к примеру. Это в редакции Server.
  3. Когда нужно использовать дополнительные скрипты для приведения приложений в целостное состояние. Тоже в редакции Server.
Тип редакции определяется ключем, и может меняться (как в VBR, переустанавливать ничего не нужно). Само собой есть триалы.

Управление и интеграция

Тут не то, что ложка чего-то непотребного в бочку, просто вопрос времени. Бэкап для вас Veeam уже сделал - остальное чуть позже.

1. Интеграция с Veeam Backup & Replication 9.5. Будет с выходом Update 1 для последнего.
К слову, в Update 1 появится и поддержка vSphere v6.5.
Когда? Как будет готов :). Подождите три-четыре недели.

2. Управление.
Тут тоже есть нюансы. Во-первых, есть интерфейс. Во-вторых, есть командная строка. А значить уже можно скриптовать.
Вот так можно экспортировать и импортировать настройки:
veeamconfig config export --file config.txt
veeamconfig config import --file config.txt
Но, зная как Veeam приучил пользователей своих продуктов, что все должно работать просто и удобно даже в матёром энтерпрайзе, предвосхищаю как пользователи начнут требовать красивых гламурных интерфейсов для глобального управления 100500 Linux-серверов. И тут я вам скажу снова: ждите. Veeam Availability Console ожидается в следующем году (кстати, с Наступающим! ;)):

Гикам на закуску

Ну, а чтобы сгладить ожидание вот вам исходники на наши драйвера для создания снапшотов и наша реализация отслеживания измененных блоков данных для копирования инкрементов (changed block tracking) на GitHub-е: https://github.com/veeam/veeamsnap (лицензия GPL v2).

Ссылки

Что такое облако (по ГОСТу)

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

Давно я жаловался, что нет у нас устоявшейся терминологии в понятии и определении что такое "облачные вычисления", "облака" и т.п. Пять лет назад NIST опубликовали свой "definition", а я его даже перевел. Но все равно, раз за разом, на конференциях со множеством участников начинается всё со спора о высоком (как правильно, что лучше, где больше), а скатывается в банальный спор о терминах (как, что и где) - кто как эти термины понимает и трактует...

Наконец-то появилось и у нас определение. Да оригинал - европейский, и язык оригинала - немецкий. А при разработке все равно использовались стандарты, упомянутые выше - по-NISTу. Но это официально принятый документ и в ЕС, и в России (а еще в Армении, Беларуси, Киргизии и Таджикистане). Правда в России он официально действует с 1.11.2017 - т.е. будет действовать. Не понимаю, что он будет делать год, и зачем этот период, если там все равно фактически только определения.
Но, самое главное, знайте - у нас есть стандарт! И учите матчасть.

Ссылка: ГОСТ ISO/IEC 17788-2016 (Как оттуда скачать в pdf?)