Зря вы так, китайские телефоны уже давно нормальные, тут немало статей на эту тему.
А на ифонах тормозов и разрывов производителем не предусмотрено (но на самом деле нет).
Так кластер или репликация?
У нас в 9.1 с нативной синхронной репликацией master-slave вообще проблем нет, все само работает. Если уже совсем сломалось, то две команды в консоли все починят.
Виртуалки openvz, штук 6 в среднем для всех задач. В каждой 4 камня, 250 Gb disk, 16Gb RAM. Примерно неделю хранятся сырые логи. В основном тут логи Postgres и немного Nginx. Аггрегированая и обработанная статистика от системных сервисов хранится год (собственные скрипты и pgfouine).
Ну еще у нас есть сервис с OLAP кубами, который анализирует бизнес-статистику, про них не скажу, другое подразделение занимается. Заббикс в такой же виртуалке, там данные за год, мониторится порядка 4000 элементов.
А, забыл еще сказать про профилирование скриптов приложений. Мы используем pinba, но там «мгновенная» статистика, только посмотреть и отладить, хранить ее смысла нет. Система постоянно расширяется и дополняется функционалом, вот, доросли до geo распределенного кластера, его тоже надо мониторить, причем с разных точек.
Нам недавно программисты написали тесты для своих аппликух, сейчас пробуем их запускать из Германии, например. Получается что-то типа pingdom или hosttracker, но информации внутри немного больше.
Вот у нас, фактически, тоже самое. Дополнительно еще используется graylog2, куда разработчики в real-time шлют результаты работы логики приложения. В нем есть триггеры, которые по регуляркам парсят логи и сразу поднимают тревогу, если сообщений вдруг по каким-либо причинам превышено. То есть все само аггрегируется и проводится первоначальный анализ. Это уже не системные логи, а логи работы приложения. Например, rps клиента с заданным ключом, либо как посчиталась реклама (или не посчиталась).
Критичные и нужные данные (системные и access логи), необходимые для обсчета и анализа, и которые надо хранить хоть чуть-чуть сырыми — складываются также на диск и дальше уже отложено обрабатываются парсерами и анализаторами. Ну и заббикс с кучей логики и веб-проверками.
Также наблюдается тенденция превращения наших фронтендов в web-app. Nginx может сам сформировать нужный лог (с аггрегацией и первичным анализом) и отправить куда-нибудь уже готовую статистику.
К сожалению, IT на них не заканчивается. И это очень малая часть. И там очень тихо и можно позволить себе ITIL.
Есть еще разработчики и их софт на продажу или под монетизацию, например. Социальные сети, сервисы, геолокация, навигация, геймдев. Там счет идет на часы. Конкурентов слишком много.
Давайте поговорим об инцидентах.
ITIL предлагает в качестве инструмента для объективного указания приоритета параметры, срочность и влияние.
У нас есть первая линия, хелпдеск, которая должна объективно определить срочность. Как? Со слов пользователя?
У пользователя для всех его заявок всегда один и тот же приоритет. Точнее целый набор: «жить не могу», «сверхсрочно» и «сделать вчера!».
Опросные листы? А есть примеры реально работающих оперативных анкет по определению срочности? Приведите, я таких не встречал еще. Определять срочность, пользуясь дистанционным доступом, дотошно проверяя слова пользователя? Долго и дорого. И не всегда помогает. Точнее никогда.
Среднестатистический helpdesk вообще слабо разбирается в бизнес-специфике большинства услуг, используемых бизнес-приложениях; если это конечно не услуги вида: «рабочее место», «печать» или «электронная почта». Да и не обязан, кстати.
Влияние? Та же песня. Зачастую невозможно определить влияние инцидента до полного его расследования.
Не работает. Необъективно ) Только для тихой рощицы торговли и чего вы там еще назвали. И то с натяжкой.
Нельзя же подойти и сказать бизнесу — извините, мы не можем развиваться так быстро, как вы хотите, потому что HP рекомендует работать по другому плану.
Это не велосипед, это — эволюция. Не всем это пока надо, но успешным компаниям, которые развиваются и конкурентноспособны — почему нет )
backup — ну, он не нужен. Точнее он почти не нужен, весь код децентрализован и хранится распределенно в системе контроля версии. Исходные данные тоже нужно бекапить. И все ))
Упала виртуалка, две, три, сервер, второй, третий. Это неважно. Деплой запускается быстро на других нодах. Нет ноды — он полетит в коммерческое облако. Данные избыточны и легко восстановимы. Вместо 300 единиц всего мы бекапим только две и самое важное там.
Возьмем, например, change management, чтобы не быть голословным.
Нужно изменить конфигурацию сервера, ввести новый сервис, новую фичу — нужен план, его необходимо утвердить, применить, обновить документацию и прочие бюрократические штуки.
Разработчики у нас релизятся несколько раз в день. Чтобы поддержать только документацию в актуальном состоянии — нужна прорва времени. Еще время на утверждение, внедрение, тестирование и прочее.
Времени нет совсем. Если мы будем тратить его на бюрократию, конкуренты нас сомнут и съедят.
Есть система автодеплоя, инструкции которой и служат собственно документацией, а разработка и эксплуатация работает в таких экосистемах, где все автотестится и автодеплоится. Каждый разработчик немного админ и осознает, что он кодит и как это повлияет на экосистему. Каждый админ осознает, как работает этот код и что будет с экосистемой после релиза. Все автоматизировано. Это работает.
ITIL устарел и зачастую больше вредит. Не все сразу, но большие части. Бизнес слишком быстро развивается и много требует, взгляд на него кардинально поменялся за 20 лет.
DevOps — вот будущее.
Я написал, как пользователь. И привел пример. Какая разница, где я работаю. Если бы слова были голословны, то я бы был простым троллем и можно было фукать и стыдить. По существу есть что ответить?
UniFi — хорошо. Тоже сейчас используем, довольны, как слоны. Раньше мастерили «из того, что было», все проблемы данный комплекс решает легко и непринужденно. Иногда кажется, что скайнет именно так и начинался )
Новосибирск, андроид с 4.0.4 — есть информация о локальном траффике. Вполне достоверно. Им проще, аппараты с андроидом — распространенное явление, много входной информации, при этом клиенту ничего специально запускать не надо.
А на ифонах тормозов и разрывов производителем не предусмотрено (но на самом деле нет).
У нас в 9.1 с нативной синхронной репликацией master-slave вообще проблем нет, все само работает. Если уже совсем сломалось, то две команды в консоли все починят.
Ну еще у нас есть сервис с OLAP кубами, который анализирует бизнес-статистику, про них не скажу, другое подразделение занимается. Заббикс в такой же виртуалке, там данные за год, мониторится порядка 4000 элементов.
А, забыл еще сказать про профилирование скриптов приложений. Мы используем pinba, но там «мгновенная» статистика, только посмотреть и отладить, хранить ее смысла нет. Система постоянно расширяется и дополняется функционалом, вот, доросли до geo распределенного кластера, его тоже надо мониторить, причем с разных точек.
Нам недавно программисты написали тесты для своих аппликух, сейчас пробуем их запускать из Германии, например. Получается что-то типа pingdom или hosttracker, но информации внутри немного больше.
Критичные и нужные данные (системные и access логи), необходимые для обсчета и анализа, и которые надо хранить хоть чуть-чуть сырыми — складываются также на диск и дальше уже отложено обрабатываются парсерами и анализаторами. Ну и заббикс с кучей логики и веб-проверками.
Также наблюдается тенденция превращения наших фронтендов в web-app. Nginx может сам сформировать нужный лог (с аггрегацией и первичным анализом) и отправить куда-нибудь уже готовую статистику.
Есть еще разработчики и их софт на продажу или под монетизацию, например. Социальные сети, сервисы, геолокация, навигация, геймдев. Там счет идет на часы. Конкурентов слишком много.
И там тоже есть среднестатистические админы )
ITIL предлагает в качестве инструмента для объективного указания приоритета параметры, срочность и влияние.
У нас есть первая линия, хелпдеск, которая должна объективно определить срочность. Как? Со слов пользователя?
У пользователя для всех его заявок всегда один и тот же приоритет. Точнее целый набор: «жить не могу», «сверхсрочно» и «сделать вчера!».
Опросные листы? А есть примеры реально работающих оперативных анкет по определению срочности? Приведите, я таких не встречал еще. Определять срочность, пользуясь дистанционным доступом, дотошно проверяя слова пользователя? Долго и дорого. И не всегда помогает. Точнее никогда.
Среднестатистический helpdesk вообще слабо разбирается в бизнес-специфике большинства услуг, используемых бизнес-приложениях; если это конечно не услуги вида: «рабочее место», «печать» или «электронная почта». Да и не обязан, кстати.
Влияние? Та же песня. Зачастую невозможно определить влияние инцидента до полного его расследования.
Не работает. Необъективно ) Только для тихой рощицы торговли и чего вы там еще назвали. И то с натяжкой.
Это не велосипед, это — эволюция. Не всем это пока надо, но успешным компаниям, которые развиваются и конкурентноспособны — почему нет )
Упала виртуалка, две, три, сервер, второй, третий. Это неважно. Деплой запускается быстро на других нодах. Нет ноды — он полетит в коммерческое облако. Данные избыточны и легко восстановимы. Вместо 300 единиц всего мы бекапим только две и самое важное там.
Нужно изменить конфигурацию сервера, ввести новый сервис, новую фичу — нужен план, его необходимо утвердить, применить, обновить документацию и прочие бюрократические штуки.
Разработчики у нас релизятся несколько раз в день. Чтобы поддержать только документацию в актуальном состоянии — нужна прорва времени. Еще время на утверждение, внедрение, тестирование и прочее.
Времени нет совсем. Если мы будем тратить его на бюрократию, конкуренты нас сомнут и съедят.
Есть система автодеплоя, инструкции которой и служат собственно документацией, а разработка и эксплуатация работает в таких экосистемах, где все автотестится и автодеплоится. Каждый разработчик немного админ и осознает, что он кодит и как это повлияет на экосистему. Каждый админ осознает, как работает этот код и что будет с экосистемой после релиза. Все автоматизировано. Это работает.
DevOps — вот будущее.