Как известно, нельзя управлять тем, что не измеряешь. В контексте IT-проектов это означает необходимость мониторинга всех частей проекта: от утилизации CPU до бизнес-показателей вроде количества заказов в интернет магазине или показов баннеров на сайте.

Чтобы сервис работал стабильно и техническая поддержка могла в режиме 24/7 быть эффективной, нужно собирать метрики, визуализировать их динамику (в дашбордах и графиках), анализировать результаты и работать с инцидентами — желательно до того, как они стали инцидентами. Однако мониторинг мониторингу рознь. Он выполняет свою функцию, если система:

1) отслеживает метрики, которые нужны для принятия решений, и не мониторит лишнее;
2) уведомляет, когда ещё можно что-то сделать без последствий для работоспособности сервиса, но не спамить ложной тревогой.

Звучит просто и логично, но на практике найти баланс не всегда легко.

Эта статья будет первой в серии заметок о том, как мы организуем мониторинг у наших 400+ клиентов. Расскажем, какие метрики снимаем, каких методологий придерживаемся и какие алерты видим каждый день.

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

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

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

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

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

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

Введение

Образы в WIM формате, подготовленные в системе MDT, компания Microsoft предлагает развертывать по сети с помощью WDS-сервера, либо интегрировать в SCCM.
SCCM стоит довольно дорого, а вот WDS-сервер бесплатен в случае, если вы являетесь счастливым обладателем лицензии на Windows Server 2008/2012. Но не всех устраивают возможности WDS-сервера.
Предлагаемый мной способ будет полезен тем:

• у кого нет лицензии на Windows Server, или все ресурсы на имеющихся серверах уже задействованы и нет возможности приобрести еще одну лицензию;
• кого не устраивает скорость загрузки Windows PE по протоколу TFTP, используемому WDS-сервером;
• кому необходимо совместить развертывание ОС Windows и Linux по сети на одном сервере.

Хочу предложить читателям решение на базе ОС Ubuntu Linux, с использованием syslinux и iPXE.