Насколько просто выявить проблемы в IT-системе.

 

   Довольно часто от клиентов можно услышать

 

   – Давайте мы сами будем оптимизировать. Вы просто недельку проведите обследование, выявляете все проблемы и сделайте по ним отчёт, с указанием приоритетности, а мы их исправим.

 

      Несмотря на все уверения заказчика перед началом проекта - если мы согласимся, и просто сделаем отчёт с рекомендациями – никто не примет эти работы, пока по этим рекомендациям не будет достигнут заметный эффект по производительности.

 

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

 

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

 

Узкие места системы обладают свойством скрывать друг друга.

 

      Как следствие, пока не решишь одни проблемы – не увидишь другие.

Приведу абстрактный пример: Пусть у вас есть программист Василий, который не делает поручаемую работу. Мы проводим в течении двух дней обследование, и выявляем, что Василий все два дня болел простудой – делаем отчёт и пишем рекомендацию – увеличить устойчивость Василия перед простудными заболеваниями. Допустим, что проведя профилактические работы заказчик добился того, что Василий закалился и теперь не кашляет. Но хотя наши рекомендации выполнены – он по-прежнему не делает свою работу. Хотя мы свои обязательства уже выполнили, и выявили все проблемы, которые можно было выявить без вмешательства – приходится проводить повторное обследование, допустим выявляется,  что Василий был два дня на работе, но не работал над порученными задачами, потому у Васи зарплата в 10 раз меньше той, которую он хочет, и поэтому за рабочим местом Вася делает работы на заказ другим фирмам, которые платят больше. Дополняем первый отчёт, рекомендацией повысить Васе зарплату, и увеличить мотивацию. Допустим заказчик снова применяет рекомендации, но работа так и стоит, и следующим этапом мы выясняем, что руководитель не занимается чёткой постановкой задач. Василий просто не в курсе того, что нужно делать и какие задачи наиболее приоритетны, . … Можно очень долго продолжать этот пример, но суть в том, что выявление проблем – процесс итерационный и неразрывно связанный с их поэтапным решением. Добиться результатов за один приём можно только в самых простых случаях.

 

Часть проблем носят вероятностный характер.

 

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

 

      В итоге небольшой проект по выявлению проблем в системе – обязательно перерастает в масштабные работы по оптимизации работы системы.