Расширили сеть в российской локации



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

Активно занимаемся проработкой вариантов альтернативной Anti-DDoS защиты к уже имеющейся, а текущую будем модернизировать, после чего будет увеличена максимальная мощность атак, которую мы можем отражать.
Касаемо того будет ли защита стоить каких-денег, на данный момент информации нет. Скорее всего, текущая защита останется бесплатной, альтернативная/новая — платной.

https://www.ipserver.su

Нерабочий апрель и рабочие апдейты от MCS



Мы открыли Arenadata DB как сервис
Новый сервис управляемой облачной СУБД — Arenadata DB, мощная распределённая аналитическая база данных на основе Greenplum для больших данных в больших проектах. В списке сервисов новую СУБД можно найти в разделе Аналитические БД.

Запросите Trial и попробуйте Arenadata DB в тестовом периоде
mcs.mail.ru/databases/arenadata-db/?

Смотрите видео о внутреннем устройстве Greenplum с нашего @Databases Meetup:

Раздел «Виртуальные сети»
Разделы Настройки Firewall, Балансировщики нагрузки, Сети и VPN перенесены из раздела Облачные вычисления в новый раздел личного кабинета MCS: Виртуальные сети.

Документация по этим настройкам тоже объединена.
mcs.mail.ru/help/network

Резервное копирование кластера Kubernetes в MCS с помощью Velero
Velero — инструмент для резервного копирования объектов Kubernetes, включая копии Persistent Volumes, в объектное хранилище. Velero идеально подходит для плана аварийного восстановления и создания бекапов при подготовке кластера к обновлению. Теперь Velero совместим с кластерами Mail.ru Cloud Containers и нашим объектным хранилищем.
Как настроить взаимодействие Velero с кластером Kubernetes на MCS и его бекапирование в объектное S3-хранилище MCS
mcs.mail.ru/help/backup-k8/kubernetes-velero
mcs.mail.ru/help/backup-k8/kubernetes-velero

Доступны инстансы с ОС openSUSE
Теперь при создании инстанса можно выбрать ОС SUSE Linux Enterprise Server. Эта ОС рекомендована для запуска нагрузок SAP и проходит регулярную сертификацию ФСТЭК. Пользователи MCS получат доступ к русскоязычной технической поддержке компании SUSE.

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


Почитать
Хабр: Базы данных в IIoT-платформе: как Mail.ru Cloud Solutions работают с петабайтами данных от множества устройств
VC: Тренды интернета вещей: ИИ отвечает на звонки, облака и 5G приручают big data, ЖКХ — лидер инноваций
Узнавайте о новостях MCS в нашем Телеграм-канале.

Знакомые продукты Microsoft в Яндекс.Облаке



Удалённые рабочие столы по RDP, настройка Active Directory, развёртывание почтового сервера или 1С с MS SQL — всё выполнимо на базе Яндекс.Облака.
Мы записали вебинар и подготовили пошаговые инструкции для работы с сервисами:
Стоимость
Размещать сервисы в Облаке выгодно — посмотрите здесь сравнение цен. Стоимость с Windows Server Standard зафиксирована и не зависит от конфигурации ВМ. Для конфигураций от 8 ядер Windows Server Standard выгоднее, чем Windows Datacenter.
cloud.yandex.ru/promo/ws-in-cloud/

Приглашение | AWS Startup Webinar Series | 20 Мая

AWS Startup Webinar Series
AWS Startup Webinar Series будет интересен, как начинающим стартапам, так и успешным проектам, которые заинтересованы в масштабировании бизнеса.
  • Дата: Среда, 20 Мая 2020
  • Время: 10:00 — 13:30 МСК
  • Место проведения: Online
pages.awscloud.com/EMEA-field-T2-AWSStartupSeries-2020-reg-event.html

Product updates | May 14, 2020



AI & MACHINE ОБУЧЕНИЕ
Video Intelligence API — распознавание логотипа: GA

Автоматическое обнаружение, отслеживание и распознавание присутствия более 100 000 брендов и логотипов в видеоконтенте.
cloud.google.com/video-intelligence/docs/logo-recognition

COMPUTE
Рекомендатель — понимание типов: бета

Настройте Рекомендатор для предоставления подробных аналитических данных, рекомендаций и средств автоматизации с использованием типов аналитических данных, включая межсетевые экраны и типы IAM, для более эффективной, безопасной и менее трудоемкой работы среды Google Cloud.
cloud.google.com/recommender/docs/insights/insight-types
cloud.google.com/recommender

Compute Engine — экземпляры виртуальной машины N2D на базе AMD EPYC: GA
Используйте экземпляры виртуальной машины N2D (VM) как для рабочих нагрузок общего назначения, таких как веб-серверы и тестирование, так и для рабочих нагрузок, требующих высокой пропускной способности памяти, таких как анализ сбоев, финансовое моделирование и рендеринг. Доступно в больших типах машин с 224 виртуальными ЦПУ.
cloud.google.com/blog/products/compute/announcing-the-n2d-vm-family-based-on-amd

Compute Engine — управление исправлениями ОС: GA
Включите автоматическое исправление гостевой среды на экземплярах виртуальной машины Compute Engine с обновлениями, выпущенными поставщиками ОС.
cloud.google.com/blog/products/management-tools/new-os-patch-management-service-protects-your-compute-engine-vms
cloud.google.com/compute/docs/os-patch-management

Compute Engine — экранированная виртуальная машина по умолчанию: GA
Защита от руткитов и буткитов, обнаружение низкоуровневых платформных платформ ваших экземпляров виртуальных машин и снижение риска отфильтрованных данных с помощью защищенной виртуальной машины — теперь по умолчанию для всех пользователей Compute Engine — без дополнительной оплаты.
cloud.google.com/blog/products/identity-security/security-simplified-making-shielded-vm-default-compute-engine
cloud.google.com/shielded-vm

КОНТЕЙНЕРЫ
Google Kubernetes Engine (GKE) — контейнеры для Microsoft Windows Server: GA
Воспользуйтесь преимуществами гибкости, скорости развертывания и упрощенного управления приложениями Windows Server с контейнерами в GKE. Запустите контейнеры Windows Server и Linux бок о бок в одном кластере для плоскости централизованного управления для обеих платформ.
Блог | Документация

ЗДРАВООХРАНЕНИЕ И НАУЧНЫЕ ЖИЗНИ
API Cloud Healthcare: GA

Надежно создавайте клинические и аналитические решения — и получайте и управляйте ключевыми данными, используя популярные стандарты данных здравоохранения, такие как HL7 FHIR, HL7 v2 и DICOM — с нашей полностью управляемой, масштабируемой средой разработки корпоративного уровня.
cloud.google.com/blog/products/containers-kubernetes/windows-server-containers-on-gke-now-ga
cloud.google.com/kubernetes-engine/docs/concepts/windows-server-gke
cloud.google.com/blog/topics/inside-google-cloud/how-google-cloud-is-supporting-healthcare-and-life-sciences-organizations

API Cloud Healthcare — потоковая передача FHIR в BigQuery: GA
Настройте API Cloud Healthcare для автоматической потоковой передачи новых и обновленных ресурсов FHIR в целевой набор данных BigQuery.
cloud.google.com/healthcare/docs/apis

Cloud Healthcare API — HL7 v2, схематизированный парсер и уведомления: GA
Укажите пользовательскую схему для синтаксического анализа входящих сообщений HL7 v2 в формате JSON с сохранением информации о группировке. Настройте хранилища HL7 v2 для публикации уведомлений по нескольким темам Pub / Sub и используйте фильтр для управления уведомлениями, отправляемыми в каждую тему.
cloud.google.com/healthcare
cloud.google.com/healthcare/docs/how-tos/fhir-bigquery-streaming

Cloud Life Sciences — новые регионы: бета
Доступ к Cloud Life Sciences в новых регионах, включая Азию-Северо-Восток1 (Токио), Азия-Юго-Восток1 (Сингапур), Европа-Запад2 (Лондон, Великобритания), Европа-Запад4 (Нидерланды), Северная Америка-Северо-Восток1 (Монреаль), США-Запад2 ( Лос-Анджелес), и США мультирегиональные (дата-центры в США).
cloud.google.com/healthcare/docs/how-tos/parser-api
cloud.google.com/healthcare/docs/how-tos/pubsub#hl7v2_messages
cloud.google.com/life-sciences/docs/concepts/locations

ИНФРАСТРУКТУРА
Новая облачная платформа Google регион: Лас-Вегас

Получите дополнительную емкость и гибкость для распределения ваших рабочих нагрузок по всей западной части США, включая наши существующие облачные регионы в Лос-Анджелесе, Солт-Лейк-Сити и Орегоне, с нашим новейшим регионом: Лас-Вегас (США-запад4).
cloud.google.com/blog/topics/infrastructure/google-clouds-las-vegas-region-is-now-open

СЕТЕВАЯ
Центр сетевой разведки — Firewall Insights: бета

Получите представление об использовании брандмауэра и обнаружите проблемы конфигурации, чтобы лучше понять правила брандмауэра и упростить настройки. Проверьте метрики в API мониторинга и в вашей облачной консоли.
cloud.google.com/network-intelligence-center/docs/firewall-insights

БЕЗОПАСНОСТЬ И ИДЕНТИЧНОСТЬ
Командный центр безопасности — аналитика работоспособности безопасности: GA

Предотвращайте угрозы с помощью постоянного мониторинга передовых методов обеспечения безопасности, выявляйте неправильные конфигурации безопасности в вашей облачной инфраструктуре Google, такие как общедоступные сегменты и открытые брандмауэры, и создавайте отчеты об уязвимостях в Security Command Center.
Документация

Обнаружение угрозы события: GA
Автоматическое сканирование и быстрое выявление опасных и дорогостоящих угроз в различных типах журналов в вашей среде Google Cloud, включая вредоносные программы, криптомайнинг, несанкционированный доступ, исходящие DDoS-атаки и грубую силу SSH.
cloud.google.com/security-command-center/docs/concepts-vulnerabilities-findings

Инвентаризация облачных активов — анализатор политики IAM: бета
Позволяет администраторам организации и папок лучше понимать политики управления учетными записями и доступом и решать задачи, связанные с аудитом и соответствием. Выполните администрирование доступа и определите, какие пользователи имеют доступ к определенным ресурсам Google Cloud.
cloud.google.com/security-command-center/docs
cloud.google.com/asset-inventory/docs/analyzing-iam-policy

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



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

Мы работаем бок о бок с некоторыми сложными заказчиками, которые внедряют приложения и сервисы следующего поколения в Google Cloud. Когда дело доходит до оптимизации затрат, есть много инструментов и методов, которые могут использовать организации. Но инструменты могут взять вас так далеко. По нашему опыту, есть несколько принципов высокого уровня, которым организации, независимо от их размера, могут следовать, чтобы убедиться, что они получают максимальную отдачу от облака.

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

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

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

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

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

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

Одним из способов решения этой проблемы является организация и структурирование ваших расходов в соответствии с потребностями вашего бизнеса. Затем вы можете углубиться в сервисы, используя отчеты Cloud Billing, чтобы получить представление о ваших расходах. Вы также можете получить более детальное представление о стоимости вашей среды, распределив затраты по отделам или командам с помощью меток и создав собственные настраиваемые информационные панели. Такой подход позволяет маркировать ресурс на основе предварительно определенной бизнес-метрики, а затем отслеживать его затраты с течением времени. В долгосрочной перспективе цель состоит не в том, чтобы понять, что вы потратили «X долларов на Compute Engine в прошлом месяце», а в том, что «это стоит X долларов на обслуживание клиентов, приносящих доход в размере Y». Это тип анализа, который вы должны стремиться создать.


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

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

Точно так же наши самые искушенные клиенты не зациклены на конкретном сокращении расходов, они задают множество вопросов, чтобы узнать их общую операционную пригодность:
  • Что мы фактически предоставляем нашим клиентам (единица)?
  • Сколько стоит мне предоставить эту вещь и только эту вещь?
  • Как я могу оптимизировать все взаимосвязанные расходы на единицу созданной?
Короче говоря, они пошли дальше и создали свою собственную модель экономики подразделения. Они задают эти вопросы заранее, а затем работают над созданием системы, которая позволяет им отвечать на эти ключевые вопросы, а также проверять свое поведение. Это не то, что мы обычно видим в клиенте состояния обхода, но многие из тех, кто находится в состоянии обхода, используют некоторые из этих концепций при разработке своей системы на будущее.

Внедрение стандартизированных процессов с самого начала
Обеспечение того, чтобы вы последовательно выполняли эти рекомендации, должно систематически разрабатываться и применяться. Инструменты автоматизации, такие как Terraform и Cloud Deployment Manager, могут помочь создать защитные ограждения перед развертыванием облачного ресурса. Гораздо сложнее реализовать стандарт задним числом. Мы видели все: от ИТ-служб, которые закрывали или угрожали отключить немаркированные ресурсы, до установленных «стен позора» для людей, которые не придерживались стандартов. (Мы поклонники позитивного подкрепления, такого как пицца, трофей или даже трофей пиццы.)

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

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


В вашей иерархии ресурсов маркировка ресурсов является главным приоритетом для организаций, заинтересованных в управлении затратами. По сути, это ваша способность приписывать затраты обратно определенному бизнесу, услуге, подразделению, руководителю и т. Д. Без маркировки ресурсов невероятно сложно определить, сколько вам стоит сделать какую-то конкретную вещь. Вместо того, чтобы говорить, что вы потратили 36 000 долларов на Compute Engine, лучше иметь возможность сказать, что вы потратили 36 000 долларов на доставку мемов 400 000 пользователей в прошлом месяце. Второе утверждение гораздо более проницательное, чем первое. Мы настоятельно рекомендуем создавать стандартизированные ярлыки вместе с командами инженеров и финансов и использовать ярлыки для максимально возможного количества ресурсов.

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


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

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

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

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

Оптимизация использования ресурсов — это сокращение отходов в вашей среде за счет оптимизации использования. Цель состоит в том, чтобы внедрить определенный набор стандартов, который проводит соответствующее пересечение между затратами и производительностью в среде. Это объектив, на который следует обращать внимание при рассмотрении наличия свободных ресурсов, более качественных служб для развертывания приложения или даже более подходящего запуска пользовательской формы виртуальной машины. Большинство компаний, которые успешно избегают потерь, оптимизируют использование ресурсов децентрализованным способом, поскольку владельцы отдельных приложений, как правило, лучше всего оснащены для отключения или изменения размера ресурсов из-за их глубокого знакомства с рабочими нагрузками. Кроме того, вы можете использовать Рекомендатор для выявления проблем, таких как недостаточное или избыточное выделение экземпляров ВМ или неактивных ресурсов. Предоставление вашей команде возможности автоматически выполнять эти рекомендации является целью любых значительных усилий по оптимизации.

Эффективность ценообразования — включает такие функции, как скидки на постоянное использование, скидки на обязательное использование, фиксированная цена, тарификация в секунду или другие функции дисконтирования объема, которые позволяют оптимизировать тарифы для конкретной услуги. Эти возможности лучше всего использовать более централизованные группы в вашей компании, такие как Cloud Center of Excellence (CCoE) или команда FinOps, которые могут снизить вероятность потерь, оптимизируя покрытие во всех бизнес-единицах. Это то, что нужно продолжить, чтобы пересматривать как пред-облачную миграцию, так и регулярно, как только вы начнете жить.

Учитывая, что и люди, и процессы будут иметь большое значение для обеспечения того, чтобы ваши стандарты были полезными и соответствовали потребностям вашего бизнеса. Аналогичным образом, понимание функций видимости затрат в Google Cloud, оптимизации использования ресурсов и эффективности ценообразования предоставит вам инструменты, необходимые для оптимизации затрат для всех ваших технологий и групп.

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

Чтобы помочь вам определить приоритеты одной рекомендации по оптимизации затрат над другой, рекомендуется пометить рекомендации с оценкой двух характеристик:
  • Усилие: Предполагаемый уровень работы (в неделях), необходимый для координации ресурсов и реализации рекомендаций по оптимизации затрат.
  • Экономия. Сумма предполагаемой потенциальной экономии (в процентах на услугу), которую вы можете получить, внедрив рекомендацию по оптимизации затрат.


Хотя не всегда возможно точно оценить, насколько экономия затрат сэкономит вас перед тестированием, важно постараться сделать обоснованное предположение для каждого усилия. Например, знания о том, что определенное изменение может потенциально сэкономить вам 60% в облачном хранилище для проекта X, должно быть достаточно, чтобы помочь с матрицей расстановки приоритетов и установлением приоритетов разработки в вашей команде. Иногда вы можете оценить реальную экономию. Особенно с опциями покупки, команда FinOps может оценить потенциальную экономию, используя такие функции, как скидки на обязательное использование для определенного объема своей инфраструктуры. Выполняя это упражнение, вы хотите, чтобы команда могла принимать обоснованные решения о том, куда идет инжиниринг, чтобы они могли сосредоточить свою энергию с точки зрения культуры.

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

cloud.google.com/recommender
cloud.google.com/billing/docs/onboarding-checklist#resource_hierarchy
cloud.google.com/billing/docs/how-to/reports
cloud.google.com/billing/docs/how-to/visualize-data
cloud.google.com/resources/principles-of-cost-optimization-whitepaper

Конкурс на 1000 рублей



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

Список призов:
1) 1000 рублей на баланс биллинга.
2) VDS сервер *Intel Core i7-8700 (4.6GHz) 1 vCore / 4 GB DDR4 / 100 GB NVMe* — 1 месяц.
3) VDS сервер *Intel Core I7-8700 (4.6GHz) 1 vCore / 2 GB DDR4 / 25 GB SSD* — 1 месяц.

Условия конкурса:
— Репост данной записи.
— Подписка на группу хостинга.
— Присутствие в беседе хостинга.

Результаты будут опубликованы 1 июня в 00:00 по МСК.
Всем желаем удачи и отличного настроения!


Пост vk.com/spacecore_pro?w=wall-171073991_344

База знаний 2.0



С развитием услуг Selectel три года назад для удобства клиентов мы обновили панель управления и объединили все справочные материалы в единую систему — базу знаний.

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

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

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

Подробнее
selectel.ru/blog/kb-2-0/

Backblaze Hard Drive Stats Q1 2020



На 31 марта 2020 года компания Backblaze имела 132 339 вращающихся жестких дисков в нашей экосистеме облачных хранилищ, распределенных по четырем центрам обработки данных. Из этого числа было 2380 загрузочных дисков и 129 959 дисков с данными. В этом обзоре рассматриваются показатели Q1 2020 и частоты отказов жестких дисков на моделях накопителей данных, которые в настоящее время используются в наших центрах обработки данных, а также приводится несколько примеров и наблюдений. Кроме того, ближе к концу поста мы рассмотрим несколько прогнозов на 2019 год, которые мы представили год назад. Как всегда, мы с нетерпением ждем ваших комментариев.

Статистика отказов жесткого диска за первый квартал 2020 года
В конце первого квартала 2020 года Backblaze использовала 129 959 жестких дисков для хранения данных клиентов. Для нашей оценки мы исключаем из рассмотрения те диски, которые использовались в целях тестирования, и модели, для которых у нас не было как минимум 60 дисков (см. Почему ниже). Это оставляет нам 129 764 жестких дисков. В таблице ниже показано, что произошло в первом квартале 2020 года.


Примечания и наблюдения
Годовой процент отказов (AFR) за первый квартал 2020 года составил 1,07%. Это самая низкая AFR за любой квартал с тех пор, как мы начали отслеживать в 2013 году. Кроме того, AFR за первый квартал 2020 года значительно ниже, чем AFR за первый квартал 2019 года, который составил 1,56%.

В течение этого квартала 4 (четыре) модели дисков от 3 (трех) производителей имели 0 (ноль) отказов дисков. Ни один из дисков Toshiba 4TB и Seagate 16TB не вышел из строя в первом квартале, но в течение квартала на обоих дисках было менее 10 000 дней. Как следствие, AFR может широко варьироваться от небольшого изменения отказов привода. Например, если вышел из строя только один накопитель Seagate 16 ТБ, AFR составит 7,25% за квартал. Точно так же AFR накопителя Toshiba 4TB составит 4,05% с одним провалом в квартале.

Напротив, оба накопителя HGST с 0 (нулевыми) отказами за квартал имеют разумное количество дней накопления, поэтому AFR менее изменчив. Если бы у модели 8 ТБ был 1 (один) сбой за квартал, AFR составила бы только 0,40%, а модель 12 ТБ имела бы AFR всего 0,26% с 1 (одним) отказом за квартал. В обоих случаях 0% AFR за квартал впечатляет.

Было 195 накопителей (129 959 минус 129 764), которые не были включены в приведенный выше список, поскольку они использовались в качестве тестовых накопителей или у нас не было как минимум 60 накопителей данной модели. Например, у нас есть: 20 накопителей Toshiba 16 ТБ (модель: MG08ACA16TA), 20 накопителей HGST 10 ТБ (модель: HUH721010ALE600) и 20 накопителей Toshiba 8 ТБ (модель: HDWF180). Когда мы публикуем квартальную, годовую или пожизненную статистику накопителей, модели с менее чем 60 накопителями не включаются в расчеты или графики. Мы используем как минимум 60 дисков, так как во всех вновь развернутых блоках хранения есть 60 дисков.

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

Вычисление годовой частоты отказов
Во всех наших отчетах мы используем термин «Годовой процент отказов» (AFR). Слово «в годовом исчислении» здесь означает, что независимо от периода наблюдения (месяц, квартал) Частота отказов будет преобразована в годовой показатель. Для данной группы приводов (то есть модель, производитель) Мы рассчитываем AFR для периода наблюдения следующим образом:
  • Отказ дисков — это количество дисков, которые вышли из строя в течение периода наблюдения.
  • Дни привода — это количество дней, в течение которых все наблюдаемые диски работали в течение периода наблюдения.
  • В 2020 году 366 дней, очевидно, что в не високосные годы мы используем 365.
Пример: вычисление AFR для модели привода BB007 за последние шесть месяцев;
  • За период наблюдения (шесть месяцев) было 28 сбоев в работе.
  • В конце периода наблюдения было 6000 жестких дисков.
  • Общее количество дней работы всех накопителей модели BB007 за период наблюдения (6 месяцев) составило 878 400 дней.

За шесть месяцев модель накопителя BB007 имела годовой коэффициент отказов 1,17%.


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

Частота отказов в 0,93% по формуле количества дисков значительно ниже, что хорошо, если вы являетесь производителем дисков, но не соответствует тому, как диски фактически интегрированы и используются в нашей среде. Вот почему Backblaze выбирает метод «дни вождения», так как он лучше соответствует реальности нашего бизнеса.

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

Прогноз: Backblaze продолжит переносить диски емкостью 4 ТБ, и к концу 2019 года их будет менее 15 000: у нас сейчас около 35 000.

Реальность: количество дисков 4 ТБ по состоянию на 31 декабря 2019 года: 34 908.
Обзор: мы были слишком заняты добавлением дисков для переноса любого из них.
Предсказание. Мы установим как минимум двадцать накопителей емкостью 20 ТБ для тестирования.

Реальность: у нас ноль 20ТБ накопителей.
Обзор. Нам не предлагалось тестировать диски емкостью 20 ТБ или иным образом.
Предсказание: Backblaze превысит один эксабайт (1000 петабайт) доступного облачного хранилища. В настоящее время мы имеем около 850 петабайт доступного хранилища.

Реальность: мы объявили один эксабайт в марте 2020 года, сразу после конца 2019 года.
Рецензия: Цитируя Максвелла Смарта, «так сильно скучал».
Прогноз. Для целей тестирования мы установим как минимум 1 накопитель на основе HAMR от Seagate и / или 1 накопитель MAMR от Western Digital.

Реальность: не нюхать диски HAMR или MAMR.
Обзор: Надеюсь, к концу 2020 года.
Подводя итог, я думаю, что вернусь к статистике жесткого диска и оставлю прогнозирование предсказателям и предсказателям.

Статистика срока службы жесткого диска
В приведенной ниже таблице показана частота отказов в течение срока службы моделей жестких дисков, которые мы эксплуатировали по состоянию на 31 марта 2020 года. Отчетный период — с апреля 2013 года по 31 декабря 2019 года. Все перечисленные диски были установлены в течение этого периода времени.

Но как насчет Drive Count?
Некоторым из вас может быть интересно, где «количество накопителей» вписывается в эту формулу? Это не так, и это беспокоит некоторых людей. В конце концов, было бы проще рассчитать AFR как:
AFR = (Отказы двигателя / Счетчик движения) * (366 дней в период наблюдения) * 100

Давайте вернемся к нашему примеру в предыдущем абзаце. В конце периода наблюдения было 6 000 жестких дисков; делать математику:
AFR = (28/6000) * (366/183) * 100 = (0,00467) * (2) * 100 = 0,93%

Используя метод подсчета накопителей, модель BB007 имела частоту отказов 0,93%. Причина различия заключается в том, что Backblaze постоянно добавляет и вычитает диски. Новые хранилища Backblaze появляются каждый месяц; новые функции, такие как совместимость с S3, быстро увеличивают спрос; миграция заменяет старые диски малой емкости на новые диски большей емкости; и иногда в смеси присутствуют клонированные и временные диски. Среда очень динамичная. Количество поездок в любой день в течение периода наблюдения будет варьироваться. При использовании метода подсчета накопителей частота отказов зависит от дня подсчета накопителей. В этом случае последний день периода наблюдения. При использовании метода дней привода частота отказов определяется на весь период наблюдения.

В нашем примере в следующей таблице показано количество накопителей по мере добавления накопителей за шестимесячный период наблюдения:


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

Если вы просто хотите, чтобы сводные данные использовались для создания таблиц и диаграмм в этом сообщении в блоге, вы можете загрузить ZIP-файл, содержащий электронную таблицу MS Excel.
f001.backblazeb2.com/file/Backblaze_Blog/Q1_2020_Drive_Stats_Charts_Data.zip
Удачи и дайте нам знать, если найдете что-нибудь интересное.