Okmeter

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

О мониторинге у нас

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

1. Blackbox-мониторинг для проверки состояния сайтов. Цель проста собирать статистику с определенных endpointов и проверять их состояние по тем условиям, которые требуется установить. Например, это может быть health page в виде JSON-страницы, где отражено состояние всех важных элементов инфраструктуры, или же мониторинг отдельных страниц сайта. У нас принято считать, что данный вид мониторинга самый критичный, так как следит за работоспособностью сайта/сервисов клиента для внешних пользователей.

Вкратце о технической стороне этого мониторинга: он выполняет запросы разного уровня сложности по HTTP/HTTPS. Есть возможность определять размер страницы, ее содержимое, работать с JSON (они обычно используются для построения status page-страниц приложений клиента). Он географически распределен для повышения отказоустойчивости и во избежание всевозможных блокировок (например, от РКН).

Работа данного мониторинга не была затронута аварией благодаря геораспределенности (к тому же, у него вообще нет инсталляций в OVH).

2. Мониторинг Kubernetes-инфраструктуры и приложений клиента, запущенных в ней. С технической точки зрения этот мониторинг основан на связке Prometheus + Grafana + Alertmanager, которые устанавливаются локально на кластеры клиента. Часть данных, собираемых на данных системах мониторинга (например, метрики, напрямую связанные с Kubernetes и Deckhouse), по умолчанию отправляется в нашу общую систему, а остальные могут отправляться опционально (например, для мониторинга приложений и реакции от наших дежурных инженеров).

3. Мониторинг ресурсов, которые находятся вне кластеров Kubernetes. Например, это железные (bare metal) серверы, виртуальные машины и СУБД, запущенные на них. Данную зону мониторинга мы покрываем с помощью стороннего сервиса Okmeter (а с недавних пор уже не очень-то для нас и стороннего). Именно его работа была фатально нарушена в момент аварии OVH.

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

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

Как мы справлялись с этой аварией? Какие шаги предпринимали во время инцидента? И какие после?

Первые признаки аварии

Проверка доступности внешних средств мониторинга осуществляется с применением метода Dead mans switch (DMS). По своей сути это мониторинг, который работает наоборот:

• Создается поддельный алерт OK, означающий, что всё хорошо, и он постоянно отправляется с локальных мониторингов (Prometheus, Okmeter и т.п.) в нашу систему инцидент-менеджмента.

• Пока с мониторингом действительно всё хорошо, алерт OK активен, но в системе не показывается.

• В обратной ситуации, когда возникают проблемы с мониторингом, алерт OK перестает быть активным, из-за чего автоматически создаётся алерт ERROR о неработающем мониторинге. И вот уже на него надо реагировать.

Данная проверка очень эффективна в ситуациях, которая произошла в роковой день (10 марта): первый алерт о проблеме (ERROR) мы получили как раз от DMS.

События разворачивались следующим образом:

• Первое сообщение о проблеме алерт от DMS, полученный приблизительно в 3:20 ночи по Москве.

• Связываемся с коллегами из Okmeter и узнаем, что они испытывают проблемы с ЦОД, в котором расположены. Детальной информации на данный момент не получаем, из-за чего масштабы аварии нам неизвестны. Кроме того, дежурный инженер видит, что у нас корректно работают другие системы мониторинга (blackbox и Kubernetes). Поэтому принимается решение отложить инцидент до утра.

• Утром (в 8:14) становится известно, что ЦОД сгорел, а Okmeter не будет доступен до тех пор, пока не восстановит свою инфраструктуру в другом ЦОД.

Здесь также стоит остановиться подробнее на том, как была устроена инфраструктура у Okmeter. Основные её компоненты находились в дата-центрах OVH:

• SBG-2 который был полностью уничтожен пожаром;

• SBG-1 который был частично поврежден и обесточен.

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

Руководствуясь этой информацией утром 10 марта, мы сделали вывод, что нужно срочно замещать важные для нас функции Okmeter хоть какими-то решениями на временной основе.

Первые действия

В компании была собрана специальная команда, основными целями которой являлись:

1. Определение масштабов аварии;

2. Поэтапное планирование, как устранять последствия инцидента;

3. Дальнейшее внедрение полученных решений.

В неё вошли тимлиды наших DevOps-команд, инженеры нашей платформенной команды и CTO компании. Позже к ней также добавились отдельные инженеры, помогавшие со срочной разработкой и тестированием новых инструментов, заменивших критичные проверки от Okmeter.

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

Матрица критичности алертов

Эта матрица распространяется на события из всех 3 используемых у нас систем мониторинга. Каждому инциденту, зафиксированному в любой из систем, назначается критичность от S1 (полная потеря работоспособности компонента системы) до S9 (диагностическая информация). Большая часть алертов с критичностью S1 это blackbox-мониторинг, который проверяет состояние сайтов клиента. Однако также к этой категории относится и незначительная часть алертов, отправляемых со стороны Okmeter (подробнее о них см. ниже). Другая незначительная часть приходится на S2, а все остальные имеют более низкую критичность (S3 и т.п.).

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

Оповестив всех клиентов, инфраструктуру которых задела авария у Okmeter, мы приступили к составлению плана восстановления.

Порядок и план восстановления алертов от Okmeter

Первая очередь алертов: S1-S2

Итак, какие именно критичные алерты мы потеряли с недоступностью Okmeter? Чтобы оперативно собрать эту информацию, каждая команда инженеров тех, что сопровождают проекты с мониторингом от Okmeter, подготовила статистику алертов, приходивших с 1 июля 2020 года.

Получился следующий список:

1. Различные алерты для СУБД.

   1. Проверка работоспособности СУБД в целом (запущен ли процесс).

   2. Состояние репликации.

   3. Состояние запросов к БД (например, сколько запросов находятся в ожидании).

2. Дисковое потребление на виртуальных машинах.

3. Доступность виртуальных машин в целом.

Вторая очередь алертов: S3 и далее

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

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

Немного магического Bash

Чтобы реализовать замену проверкам и алертам Okmeter, требовалось уметь деплоить на все серверы актуальные скрипты мониторинга, чтобы поддерживать их в актуальном состоянии. Реализация: с помощью Ansible-плейбуков мы задеплоили все необходимые скрипты, среди которых был скрипт автообновления. Последний раз в 10 минут загружал новые версии других скриптов. Из-за очень сжатых сроков основную часть скриптов мы писали на Bash.

Общий подход получился следующим:

1. Сделали shell-скрипты, которые запускались на виртуальных машинах и bare metal-серверах. Помимо своей основной функции (проверка работоспособности некоторых компонентов) они должны были доставлять сообщения в наш мониторинг с такими же лейблами и другими элементами, как и у Okmeter: имя триггера, его severity, другие лейблы и т.д. Это требовалось для сохранения той логики работы мониторинга, которая была и до падения. В общем, чтобы процесс работы дежурных инженеров оставался неизменным и чтобы работали прежние правила управления инцидентами.

   Быстрой реализации этого этапа способствовал тот факт, что у нас уже были готовые инструменты для работы с API мониторинга внутренний инструмент под названием flint (flant integration).

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

3. В течение некоторого времени мы дополнительно проверяли, что алерты корректные, а сами скрипты выполняются правильно.

Результаты

На полную реализацию этого временного решения нам понадобился один рабочий день для алертов типа S1-S2 и еще один для S3. Все остальные инциденты (с более низким приоритетом) команды добавляли в индивидуальном порядке по мере необходимости.

В общей сложности новые скрипты были задеплоены примерно на 3000 хостов.

На каждом этапе решения проблемы мы подробно информировали клиентов о ходе восстановительных работ:

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

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

Выводы

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

Более практичные выводы таковы:

1. Если сервис требует повышенной отказоустойчивости, всегда важно разделять инфраструктуру не только на уровне разных ЦОД, но и географически. Казалось бы, разные ЦОДы у OVH? А в реальной жизни они горели вместе

2. В процессе подобного инцидента могут возникнуть проблемы и недопонимания в коммуникациях как между Флантом и Okmeter, так и между инженерами внутри нашей компании: недостаточное информирование о масштабах инцидента, медленная реакция и т.п. Хотя в этот раз нам повезло (их не возникло), мы пересмотрели свой регламент эскалации и еще немного ужесточили его, чтобы исключить вероятность появления таких проблем в будущем.

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

P.S.

Читайте также в нашем блоге:

• Кому-то Okmeter даже сможет заменить людей. Как будет развиваться сервис мониторинга после его покупки Флантом;

• Аварии как опыт #2. Как развалить Elasticsearch при переносе внутри Kubernetes;

• Аварии как опыт #1. Как сломать два кластера ClickHouse, не уточнив один нюанс.

Флант и Okmeter сотрудничают с 2017 года. Для Фланта Okmeter один из основных инструментов мониторинга инфраструктуры клиентов; на протяжении этих лет компании сообща улучшают его возможности.

В середине мая Флант объявил о покупке Okmeter. Несмотря на то, что для некоторых участников DevOps-рынка сделка стала новостью, во многом это естественный результат плодотворного сотрудничества двух компаний.

Чтобы ответить на накопившиеся в сообществе вопросы, мы представляем интервью с Николаем Сивко, сооснователем и теперь уже бывшим владельцем Okmeter, и Андреем Колаштовым, совладельцем и управляющим партнёром Фланта, который будет заниматься развитием проекта Okmeter. Николай и Андрей рассказали, почему компании решились на эту сделку, как она повлияет на существующих и будущих клиентов Okmeter, а также о том, в каком направлении теперь будет развиваться сервис и какую функциональность получит в ближайшее время.

Николай Сивко выступает на одной из конференций HighLoad++

О сделке и немного предыстории

Как компании к этому пришли?

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

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

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

А как появилась сама идея сделки?

Николай: Флант был у нас самым большим клиентом. В какой-то момент им стало интереснее больше влиять на продукт, быстрее закрывать конкретно свои потребности. Они захотели контролировать Okmeter. Нам эта идея понравилась.

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

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

Андрей Колаштов (в центре) на HighLoad++ Весна 2021

Николай как-то будет участвовать в дальнейшем развитии Okmeter?

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

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

Дело в том, что Флант уже многое умеет и многое знает про Okmeter. Это для них не новые ворота, не blackbox какой-то. У Фланта сформировалось собственное видение того, как развивать сервис, и они уже начали его воплощать. Скажем так, у них уже руки чешутся сделать всё как надо.

Как сделка повлияет на рынок и на клиентов

Этот кейс может как-то повлиять на местный рынок мониторинга?

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

Николай: Я думаю, сделка повлияет не столько на рынок мониторинга, сколько на рынок эксплуатации и всего, что связано с DevOps. Потому что часть того, что делает сейчас Флант как сервисная компания эту экспертизу, можно заложить в продукт. И экспертиза будет, естественно, дешевле, чем люди. Кому-то Okmeter даже сможет заменить людей.

Андрей: Да, потому что Okmeter это мониторинг, который многое делает сам. Допустим, вы поставили 5 нод, и Okmeter вам сразу всё сам замониторил. Он автоматически нашел какой-нибудь Postgres, нарисовал по нему графики, тут же зажег алерты, что у вас есть какие-то проблемы. То есть это не вы создаете и добавляете эти алерты. За вас уже подумали, в какие точки стукнуться, чтобы проверить, что у вас всё хорошо или наоборот, и почему.

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

А Okmeter делает решение, которое самостоятельно работает, причем из коробки. Это то же самое, как если бы опытный человек взглянул на графики, на алерты, и сказал: болит вот здесь.

А что касается существующих клиентов Okmeter, как продажа сервиса скажется на них?

Николай: Положительно, конечно. У Фланта есть экспертиза, которой у Okmeter не было, и клиенты теперь смогут ее получать. Флант сидит на таком потоке знаний, которого в России реально ни у кого нет. Если всю эту экспертизу привнести в мониторинг, он станет квадратично более классным.

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

Связь с инцидентом OVH

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

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

Пожар в дата-центрах OVH в марте этого года; автор фото Xavier Garreau

В чем была главная проблема с OVH?

Николай: В том, что OVH особо не рассказывал про свои дата-центры. Мы считали, что три дата-центра, в которых была размещена инфраструктура Okmeter в Страсбурге, это настоящая availability-зона, что дата-центры независимые. Мы на это полагались, и это было главной нашей ошибкой.

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

Прим. ред.: кстати, о событиях этого пожара и вынужденных действиях инженеров компании Флант мы ещё планируем опубликовать статью в скором времени.

Ближайшие планы

Как будет развиваться сервис?

Андрей: Мы видим Okmeter как несколько взаимодополняющих продуктов: хранилище, платформа и insights (идеи).

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

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

Insights это история про готовые метрики, дашборды и алерты для популярных технологий и частых кейсов. Мы создадим удобную базу из коробки. Можно сказать, что команда insights будет заниматься смыслом. Она будет разбираться с тем, что именно нужно замониторить так, чтобы действительно понимать, что происходит в сервисах, корректно ли они работают и не собираются ли упасть. Плюс эта команда будет заниматься тем, чтобы правильно строить дашборды так, чтобы была нормальная наблюдаемость (observability). Чтобы можно было посмотреть на проблему и сразу понять, как это починить, не залезая в логи. То есть, чтобы максимально ускорить процесс решения проблем.

Расскажите чуть подробнее о платформе и, в частности, об интерфейсе Okmeter: что планируете улучшить в первую очередь?

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

В командах будут только разработчики?

Андрей: В командах хранилища и платформы да. В insights и разработчики, и опытные SRE-инженеры; они будут разбираться, что у клиентов упало, почему мы не смогли вовремя это спрогнозировать и что надо замониторить, чтобы подобные проблемы предотвращать. Это будет большая команда, которая займется доработками как интерфейса, так и агента (пользовательская программа-клиент Okmeter прим. ред.), и которая будет помогать быстрее находить проблемы.

То есть это будут действующие инженеры?

Андрей: Не совсем. Они будут приходить на аварию, но не для того, чтобы починить ее, а чтобы проанализировать, почему Okmeter не предсказал эту аварию. Допустим, лежала база данных. У нее постепенно переполнялся некоторый буфер. Но графика и алертов на это переполнение не было, хотя мы могли бы за неделю до этого узнать, что буфер начал переполняться. И вот команда insights разбирается с этим, думает, как этот буфер замониторить и в итоге помочь администраторам базы сделать так, чтобы база потом не упала.

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

Андрей: Конечно. Будет очень хорошее расширение. Мы будем добавлять всё самое популярное, чего сейчас нет: MongoDB, ClickHouse, ProxySQL, HAProxy, Ceph и расширять функционал существующих. И не только базы данных. Также будем сильно расширять историю с мониторингом Kubernetes.

У Фланта, кажется, уже достаточно много наработок по мониторингу Kubernetes? Как это теперь будет совмещаться с Okmeter?

Андрей: Да, Kubernetes у нас уже замониторен своими силами. Это сделано на базе Prometheus и кучи кастомных и собственных экспортеров, чем занималась специальная команда внутри Фланта, отвечающая за платформу Kubernetes. Много сил было вложено в правильный мониторинг Kubernetes. В то же время своя интеграция с Kubernetes есть и у Okmeter. Okmeter уже работает с Kubernetes аналогично тому, как с другими сервисами и софтом на обычных узлах. То есть его можно поставить внутрь Kubernetes, он сам определит весь софт и попытается к нему подключиться, чтобы снимать метрики. Мы будем объединять эту интеграцию и наши наработки в более мощное и универсальное решение на базе Okmeter, добавляя в него наши дашборды, экспортеры и опыт в целом.

Наша детальная статистика потребления трафика по конкретному пространству имен Kubernetes-кластера

А что касается инсталляций on-premises какие здесь планы?

Андрей: Это направление мы тоже будем активно развивать. Okmeter раньше был почти для всех облачным, сейчас же появилась возможность устанавливать его on-premises силами Фланта. У нас уже есть опыт в таких инсталляциях Okmeter.

То есть будет два варианта установки?

Андрей: Да, можно будет выбирать облачную или on-premises-версию. Если вам надо, например, замониторить пару серверов и у вас нет жестких требований по безопасности, оптимальный вариант облачная версия. Если требования по ИБ высокие, можно установить Okmeter on-premises в свой закрытый контур. Хотя принцип работы тот же: ставится агент, который отправляет данные не в облако, а в локальное хранилище.

Планируете ли создание Open Source-компонентов Okmeter?

Андрей: Да. Хранилище Okmeter с большой вероятностью будет основано на Open Source-компонентах. Соответственно, все эти компоненты мы будем выкладывать на GitHub, будем в них контрибьютить и добавлять что-то, что нам помогает улучшать хранилище. Планов по открытию кода платформы и Insights в настоящий момент нет, но всё может измениться. И, конечно, это не касается тех компонентов, которые уже являются Open Source-проектами и в upstream которых мы будем приносить свои улучшения.

Николай упоминал о планах по повышению отказоустойчивости инфраструктуры Okmeter. Как именно это будет реализовано?

Андрей: Это одна из первоочередных наших задач, мы очень сфокусированы на том, чтобы сделать отказоустойчивый storage.

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

Второй шаг разместить инфраструктуру в нескольких ЦОДах, в разных странах. Клиенты смогут сами выбирать уровень отказоустойчивости, то есть сколько копий данных хранить, в каких ЦОДах.

Глобальные планы

Какова стратегия Фланта в плане повышения конкурентоспособности Okmeter на международном рынке?

Андрей: Во-первых, расширение функциональности. Обязательно будем улучшать UХ, чтобы сделать платформу реально удобной и функциональной, дополнить всем, что у нас самих болит, всем, что мы хотим замониторить.

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

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

P.S.

Читайте также в нашем блоге:

• Флант покупает компанию Okmeter;

• Флант и Okmeter: симбиоз на благо мониторинга;

• 10 лет on-call. Чему мы научились? (обзор и видео доклада).