Решение проблем с производительностью
Начнем с технических проблем.
Многим нравится, когда все данные по предприятию находятся в одной системе. Это удобно и для заказчика, и для программистов, которые жалуются на «лоскутную» автоматизацию, и для IT-директоров, которые озабочены концепцией единого информационного пространства. Но из-за этого появляются такие «монстрообразные» базы, где объем данных превышает несколько терабайт. А когда у нас в 1С базы начинают превышать определенный объем, возникают проблемы с производительностью. Что нужно делать в таких случаях:
- Самое главное – это понять, на самом ли деле вам нужно, чтобы все эти данные были в вашей базе. Первое, что надо убрать – это файлы, они в базе не нужны, т.к. будут только увеличивать размер бэкапов, и получится, что мы каждую ночь будем в полном объеме их куда-то копировать и забивать диски. Это не очень рациональное использование пространства.
- Еще бывает, что база разрастается просто из-за неправильного администрирования. Большинство таких проблем можно решить с помощью разделения баз данных на несколько путем вынесения этих баз на отдельные дисковые накопители (или на отдельные инстансы SQL). После этого система начинает работать более-менее стабильно.
Что по факту было сделано для повышения производительности?
- На INFOSTART.RU мы нашли разработку, где было реализовано хранение журнала регистрации и версий объектов в отдельной SQL-базе. Мы стали ее использовать, и она нам очень помогла, потому что часть объектов все-таки надо было версионировать, а типовой функционал версионирования сильно нагружает систему. Единственное, что я в ней переделал – это чтобы записи создавались асинхронно с помощью фоновых заданий, потому что когда эта база набрала объем, она тоже стала вызывать замедление. А после того, как все это было переписано, транзакции перестали тормозить, и мы решили две проблемы:
- Мы сохраняем информацию;
- И в то же время у нас основная база и основной дисковый накопитель освобождены от этой странной работы по хранению.
- Кстати, вынос части второстепенного функционала в фоновые задания, чтобы транзакции были короче, и не возникало блокировок – это довольно распространенный метод, советую использовать.
- Следующее, что было сделано – это перевод на управляемые блокировки. При использовании автоматических блокировок могут возникать затруднения: пользователи ждут, им это не нравится, они выражают недовольство. А когда мы переводим систему на управляемые блокировки, такого не происходит.
Но проблема в том, что мы не можем перевести на управляемые блокировки только один документ, мы должны перевести в этот режим все регистры, а значит, и весь функциональный блок. Это тяжелая работа, но, тем не менее, она оправдана. - Также нужно отметить, что высоконагруженные системы мы не имеем право отпускать в свободное плавание. Обязательно должен быть человек, администратор, который в режиме реального времени смотрит на дашборды и мониторит производительность нашей системы. В качестве дашборда может использоваться достаточно простая система Nagius. Там индикаторы имеют три цвета: зеленый, желтый, красный. Когда на горизонте беда, оно переключается в желтый цвет. Когда сервис блокируется – загорается красный. И даже можно настроить, чтобы приходила SMS – это очень удобно (хотя админу среди ночи получить "SMS счастья" не очень радостно, это лучше чем если поднимут ген. директора и он позвонит уже он самолично).
- Также на Инфостарте была статья по РАУЗ, которая помогла нам добиться прироста производительности. Там в конфигурацию надо было внести буквально несколько изменений, и после этого происходил существенный прирост.
- Еще хочу сказать по поводу нагрузочного тестирования: использование данных журнала регистрации для создания нагрузочных тестов приближает нас к тому, что мы имитируем типичную нагрузку. Например, в течение дня у нас проводятся какие-то документы, и если нам нужно проверить систему на устойчивость после внесения изменений, мы можем эти же документы просто перепровести и сделать при этом замеры. Если все получается хорошо, значит, что и в действующей системе все тоже будет хорошо. Понятно, что только проведения может быть недостаточно, потому что при реальной работе с формами могут выполняться еще какие-то дополнительные запросы к базе данных. Но, тем не менее, если мы перепроведем по журналу регистрации те же самые объекты – это будет уже больше похоже на жизнь, чем какой-то синтетический тест, который создает одни и те же документы, чтобы имитировать нагрузку.
- Для разбора проблем с производительностью используется КИП.
Ну и в целом, достаточно прозрачно и понятно, куда надо копать: читайте книжку по Эксперту, анализируйте профайлером тяжелые запросы, изучайте планы запросов идобавляйте индексы.
Также хочу поделиться простым способом организации сервис-деска: вам достаточно написать внешнюю обработку, которая будет создавать заявки в службу поддержки, и, если в вашей базе используется справочник внешних обработок, зарегистрировать ее вообще для всех документов и справочников, которые есть в системе. В результате, мало того, что вы разгружаете телефон (пользователи вам уже не звонят, они просто нажимают кнопку «Печать – сообщить об ошибке»), в автоматически сформированной заявке сразу проставляется:
- - Ссылка на тот объект, который тревожит пользователя (потому что в написанном вручную письме можно позабыть его указать).
- - Туда же можно положить сам этот сериализованный объект в виде XML, чтобы потом уже самим разбираться, что в нем было на тот момент, когда пользователь заметил ошибку - имея эту информацию не придется искать и поднимать бэкап.
Проблематика крупных проектов
Что касается пересечения технических и организационных вопросов:
- К сожалению, если мы выполняем обязанности руководителя крупных проектов, нам приходится отходить от технических вопросов, от архитектуры в сторону коммуникаций, потому что кроме нас этого никто не сделает. Например, в проекте автоматизации правительства Москвы было плотно задействовано четыре организации, а значит, что со всеми представителями надо было постоянно встречаться и согласовывать то, что они хотят. Если они все находятся в центре, то четыре встречи можно и за день провести, но если они у вас территориально разнесены, или вообще участвует несколько городов, то это уже сложнее.
- В тех случаях, когда требуется планирование, мы не можем пустить все на самотек, потому что если пытаться все держать в голове, то проект 100% завалится – следовательно, нужен соответствующий инструментарий.
- Что касается инструментария, то самое первое – Google-документы. В современных телефонах для работы с ними есть практически все, что нужно. А если этого недостаточно, то потом подробнее расскажу еще и про инструментарий на базе 1С.
Что касается деятельности руководителя проекта, то основные моменты, которые обсуждаются у нас на совещаниях, это содержание и интеграция (потому что много систем взаимодействует между собой). И больше всего проблем возникает как раз с согласованием интеграционных вопросов, потому что у системы много хозяев, и каждый из них пытается «тянуть одеяло на себя». В связи с этим хотелось бы предостеречь коллег от ошибки:
- Почему-то программисты предпочитают всю информацию закачивать к себе в базы и потом ее синхронизировать, чтобы быть хозяевами всех данных и хранить все у себя.
- во-первых, это невозможно – все равно все к себе не утащишь.
- а во-вторых, у нас сейчас все-таки не 90-е годы, и уже давно повсеместно используются веб-сервисы, которые позволяют в оперативном режиме «выдергивать» из других баз только то, что нужно. А брать функции хранителя всех ключей от данных на себя – не совсем правильное решение.
Согласование требований
Что касается согласования требований:
- Наивысшие риски в тех проектах, где заказчик не знает чего хочет. Но слава Богу таких проектов не очень много, хотя технари очень любят употребить это словосочетание по поводу и без.
- Обычно заказчик знает, чего хочет, но иногда только в общих чертах, и сформулировать это может только приблизительно, общими словами. Поэтому ему надо рассказать, как это вообще делается. И да, это уже операционный консалтинг. Можете открещиваться от этого, но можете предоставить и такие услуги, от вас не убудет - и заодно создадите себе дополнительную ценность на рынке.
- На момент начала крупного проекта мы должны не пытаться что-то изобретать с нуля, а иметь уже какие-то готовые паттерны, что это делается так-то и так-то.
- И, наконец, не все паттерны одинаково полезны для конкретного заказчика.
Большинство проблем нужно стараться отсечь сразу, на этапе формулирования требований, чтобы избежать заведомо неправильных решений. Типичная ситуация: мы автоматизируем машиностроительный комплекс, и вместо одной сборочной спецификации хотим создать 10, по каждой операции (например, гайку прикрутили – новая деталь). Получается очень много промежуточных ходов, которые никто не сможет вести - слишком большой объем информации,тем более что в результате такого решения мы выигрываем только то, что видим остатки по этим гайкам в производстве (что мы их не сразу употребили на сборку, а по одной). Если это никому не нужно, и от таких вещей заказчика нужно уберечь. Поэтому сразу убирайте неправильные варианты.
Инструментарий для управления проектом
Переходим к инструментарию, который был разработан для управления проектом.
Когда-то для этих целей мы в Газпроме использовали Jira, но потом сделали систему на 1С, потому что я, как Java-разработчик и как автор плагинов для Jira, могу сказать, что писать такие плагины довольно трудоемко: это занимает много времени и только лишь компилируется несколько десятков минут. Сейчас я считаю, что брать Jira и расширять ее плагинами – не очень правильно. Поэтому, раз уж у вас есть лицензия на 1С, лучше взять какое-то готовое решение или сделать его с нуля. Даже если вам, например, не нравится веб-клиент 1С, другой докладчик здесь же на конференции представил альтернативный, и это не может не радовать.
На слайде представлена архитектура нашего инструментального приложения. Конечно, это уже не газпромовская архитектура, потому что за то время, которое прошло с тех пор, мое видение сильно скорректировалось. Например, когда меня попросили разработать курс по управлению проектами в учебном центре при МГТУ им. Баумана, я, в процессе его проведения, получал обратную связь от участников. А когда людей и точек зрения много, это помогает снять замыленность взгляда. В том числе на основе этой обратной связи в архитектуру были внесены существенные корректировки. Поэтому на данном слайде отражен обобщенный результат этой архитектуры.
- В центре вы видите большой блок управления денежными средствами. Он необходим в тех случаях, когда вы работаете с субподрядчиками, и вам надо управлять взаиморасчетами с ними, иначе у вас может случиться большое горе. Например, когда заказчик не перечисляет вам деньги, а у вас по договору с субподрядчиком уже есть обязательство, что ему нужно заплатить, чтобы он продолжал на вас работать. В этих случаях вы в платежном календаре видите провал (кассовый разрыв): вам еще не заплатили, а вы уже должны. И это – очень важная часть управления проектом.
Но если у вас своя внутренняя команда и вам это не нужно, тогда – другое дело, тогда этот кусок можно выбросить. - Что касается планов, там также есть документы планирования.
- Ну и самое главное, что в нашем инструментарии можно хранить все данные, которые у вас в голове не помещаются, и отслеживать их выполнение по реперным точкам.
По поводу работы с различными вариантами проектного инструментария у нас были дискуссии на предварительных встречах в «Клубе экспертов» – там люди говорили, что ничего из этого не работает, договорились даже до того, что методика GTD (Getting Things Done) не работает. Я с этим не согласен, мне это напоминает анекдот про блондинку, которая звонит своему мужу и говорит:
«Дорогой, я еду по трамвайным путям, за мной гонится трамвай, что мне делать?» На что муж ей отвечает: «Посмотри по навигатору, куда тебе ехать». А она ему: «Не могу посмотреть по навигатору, я с ним поругалась».
Соответственно и вы, как руководитель проекта, тоже можете со своим инструментарием «поругаться» и его не использовать, но на проекте за вами гонится не трамвай, который может остановиться, а дедлайн. И дедлайн не остановится, он вас задавит. А позвонить кому-то, кто решил бы эти проблемы за вас, вы, к сожалению, не сможете.
Заключение
На что еще хотелось бы обратить внимание?
- Вчера коллега рассказывал, что если вы не пишете документов, то вы не управляете рисками. Однако даже если вы составили прекрасную документацию, но не установили порядок ее исполнения, то эти документы остались на бумаге и не пошли в жизнь вашей организации. Соответственно, вы все равно не достигли управления рисками, потому что, кроме того, что нужно составлять документы, гораздо важнее еще и фиксировать результаты мероприятий по рискам, вести мониторинг изменений вероятности реализации рисков. То есть, вы заложили риск смены собственника, и на момент начала проекта она была 5%, а в середине стала 95%. Самое время остановить работы и перейти на предоплату - но где тот красный огонек который об этом просигнализирует? В моей архитектуре это предусмотрено.
- Также в управлении рисками очень важно выделить особый риск, который связан с тем, что вы пообещали заказчику на пресейле. Например, вы пообещали ему увеличить производительность – такое же часто бывает? Для чего может быть нужна информационная система? Конечно, самый первый аргумент - для увеличения производительности, потому что нужно обслуживать больше заказов и производить больше продукции. Например, вы пообещали заказчику достигнуть каких-то определенных цифровых показателей. А потом, после того как вашими разработчиками было написано ТЗ, и согласно ему у заказчика прошло внедрение, вряд ли кто-то замерял, были ли достигнуты те значения показателей, которые были изначально обещаны. Может случиться, что после внедрения эти показатели даже ухудшатся. Почему? Потому что когда две системы работают в параллель, то очевидно, что человек тратит на них больше времени. Или, если он еще не привык к новой системе, и у нее есть какие-то недостатки, на работу тоже будет тратиться больше времени. И получается, что у вас вроде все юридически правильно: вы сделали систему, которая соответствует согласованному ТЗ (хорошо, если она соответствует). И юридически – вы правы, но по понятийным договоренностям – нет. Вы обещали улучшить, а получилось, что ухудшили. Поэтому очень важно замерять результаты обещанных показателей. Тогда можно выявить, что они еще не достигли целевых значений, и проанализировать, почему. Например, можно подойти с таймером к пользователю и замерить, сколько времени он тратит на оформление той или иной операции. И если он работает медленно, то сразу становится понятно, почему у него что-то не получается. А если не знать, что производительность упала, то, соответственно, и заниматься этим тоже никто не станет, и у клиента, даже если он заплатил вам деньги, все равно останется такое «послевкусие», что его обманули. А это очень плохо, потому что новых заказов вы от него больше не получите. Поэтому всегда измеряйте ключевые показатели, чтобы ваши клиенты были вами довольны.
Еще хочу сказать про разницу в отношении к коммуникационным проблемам у программистов и менеджеров.
- Например, когда у программиста в плане работы над проектом раз в неделю стоит встреча с сотрудниками заказчика, а он с кем-то из них поругался, то он эти встречи прекращает, говорит, что у него сейчас много другой важной работы, надо код писать, некогда ему с кем-то встречаться.
Или когда программист сталкивается с организационной проблемой (главный бухгалтер у него не хочет принимать работу), он на нее обижается, объявляет ее ведьмой-чернокнижницей и говорит: «мы с ведьмами переговоров не ведем, мы их сжигаем на костре». Что он делает дальше? Он начинает искать единомышленников и собирает толпу, чтобы действительно эту ведьму сжечь. Но за последние 10 лет я не слышал, чтобы кого-то из управленцев сожгли, или хотя бы уволили из-за конфликта с программистами: они не достигают такой степени влияния в организации клиента, чтобы по своему желанию кого-то увольнять. Значит, это – неконструктивная позиция, и если мы обрезаем коммуникации в период, когда начинаются проблемы – это совершенно точно путь к провалу проекта. И если дедлайн наступит, а мы ничего не сдали, то получится, что на нас лежала ответственность, а мы по каким-то эмоциональным причинам все провалили. - А менеджер – наоборот, в случае проблем усиливает коммуникации. Он может выслушать заказчика, не воспринимая его критику близко к сердцу, и это – то, что называется стрессоустойчивостью в требованиях к вакансиям. Тогда у человека запал пройдет, и мы сможем решить проблему более конструктивно: работы понемногу станут приниматься, документы подписываться и т.д. Бывало, я общался и по полчаса с людьми, только для того, чтобы снизить накал и перейти в конструктив. Да, это не просто, но после выработки иммунитета - вполне осуществимо.
Так что коммуникации – это очень важно, и выделенный менеджер, в частности, нужен именно для этого.
***********
Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2015 CONNECTION 15-17 октября 2015 года
Приглашаем вас на новую конференцию INFOSTART EVENT 2019 INCEPTION.
