К сожалению, это конфиденциальная информация. Но изменение действительно в разы. Но тут нужно учитывать, что увеличение стоимости инфраструктуры сопоставимо с стоимостью пары товаров в ИМ, так что оно стоит того.
Больше -- точно нет, скорее также. Тут эффект немного другой. Если судить по разговорам с коллегами, они стали тратить меньше времени и сил на рутинные операции и теперь у них больше того и другого для более важных задач. Поэтому выросло удовлетворение от работы. Ведь важные задачи решаются и ощущения, что тонешь в рутине, становится меньше. И так как мы говорим в основном про руководителей, то это положительно влияет не только на их мотивацию, но и мотивацию всех команд в целом.
Если вопрос в разрезе "разные источники данных", то это данные от таск-трекера, системы мониторинга, с серверов авторизации и от некоторых других наших внутренних сервисов.
У нас есть опытные данные по предыдущим проектам: сколько времени на те или иные работы уходит у менеджеров. Это помогает примерно планировать нагрузку по новым работам. Также мы логируем рабочие чаты — это полезно и с точки зрения подсчета временных затрат, и чтобы не забывать, о чем идет речь в коммуникациях с клиентами. Ну и, конечно, менеджеры сами фиксируют время, потраченное на рабочие задачи: проверки статусов, созвоны и тд.
В случае с USE-метриками мы анализируем систему и находим бутылочное горлышко. Потом предлагаем клиенту конкретные планы по исправлению ситуации вместе с прогнозом, если это возможно. Но исправление может требовать дополнительных затрат, поэтому конечное решение принимает клиент.
В случае с RED-метриками еще интереснее, потому что с точки зрения бизнеса то, что мы видим как алерт, может не всегда являться проблемой для бизнеса. Но в любом случае все предложения будем строить на анализе.
Технически, как минимум пяток недовольных мейнтейнеров. Кроме Arch Linux, Chromium выпиливают еще куча команд различных дистрибутивов, о чем, кстати, написано в посте :)
К сожалению, это конфиденциальная информация. Но изменение действительно в разы. Но тут нужно учитывать, что увеличение стоимости инфраструктуры сопоставимо с стоимостью пары товаров в ИМ, так что оно стоит того.
Пожалуйста, Волжанин63, изучайте на здоровье, -- ответил вам Сергей.
Совершенно справедливое замечание. Более того, реализовать это в такой инфраструктуре очень просто. Но в этом проекте такой потребности не было.
Собственно статья и была задумана как текст про пляски с бубном) А пафосный кейс уже на подходе, не переключайтесь;)
Больше -- точно нет, скорее также. Тут эффект немного другой. Если судить по разговорам с коллегами, они стали тратить меньше времени и сил на рутинные операции и теперь у них больше того и другого для более важных задач. Поэтому выросло удовлетворение от работы. Ведь важные задачи решаются и ощущения, что тонешь в рутине, становится меньше. И так как мы говорим в основном про руководителей, то это положительно влияет не только на их мотивацию, но и мотивацию всех команд в целом.
Нет, таск-трекер один.
Если вопрос в разрезе "разные источники данных", то это данные от таск-трекера, системы мониторинга, с серверов авторизации и от некоторых других наших внутренних сервисов.
Спасибо, приятно слышать :-)
Тут мы используем стандартную копипасту для sysctl , которую применяем для всех наших серверов.
Её достаточно в большинстве случаев.
Вопрос не к нам, но всё же позволю себе заметить, что, учитывая большое количество свободной памяти, свап следует исключить.
У нас есть опытные данные по предыдущим проектам: сколько времени на те или иные работы уходит у менеджеров. Это помогает примерно планировать нагрузку по новым работам. Также мы логируем рабочие чаты — это полезно и с точки зрения подсчета временных затрат, и чтобы не забывать, о чем идет речь в коммуникациях с клиентами. Ну и, конечно, менеджеры сами фиксируют время, потраченное на рабочие задачи: проверки статусов, созвоны и тд.
Внедрённая у себя внутри система аналитики стала основой для создания платформы обработки и хранения больших данных — ITS DPP.
Ну, а DIY — вроде понятно: собрали платформы своими руками...
Красота в глазах смотрящего, как известно ;-)
Как-то потерялось. Речь идет о 4000 серии, сейчас добавим.
Привет! Бывает по-разному.
В случае с USE-метриками мы анализируем систему и находим бутылочное горлышко. Потом предлагаем клиенту конкретные планы по исправлению ситуации вместе с прогнозом, если это возможно. Но исправление может требовать дополнительных затрат, поэтому конечное решение принимает клиент.
В случае с RED-метриками еще интереснее, потому что с точки зрения бизнеса то, что мы видим как алерт, может не всегда являться проблемой для бизнеса. Но в любом случае все предложения будем строить на анализе.
Термин не новый, не мы его придумали :-) Например, вот — https://www.ibm.com/docs/ru/ram/7.5.3?topic=planning-websphere-application-server-clusters
Другое дело, что тут правильнее употребить предложенный вами вариант. Внесли исправление, спасибо!
Исправили, спасибо!
Откуда взялось 250 триллионов долларов США?