Мы в «Латере» уже много лет занимаемся разработкой биллинга для операторов связи и развиваем сервис для управления выездными сотрудниками «Планадо».

Биллинг — это сложный продукт, работа над которым имеет свои особенности. Во-первых, это узкоспециализированный инструмент enterprise-уровня, который внедряется сотнями экземпляров, а не десятками и сотнями тысяч. Во-вторых, система должна работать в режиме 24x7x365. И самое главное — именно биллинг считает деньги, а значит это критически важный элемент инфраструктуры любой компании.

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

Сразу думайте о будущих доработках

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

Иллюстрация из близкой нам сферы телекоммуникаций — разные операторы требуют разных возможностей биллинга. Свои особенности телеком-отрасли могут быть в разных регионах — к примеру, в Норильске и Магадане нет проводных каналов связи, доступен только спутник. Поэтому доступ в интернет здесь очень дорогой и до сих пор в ходу тарифы с квотами трафика. Такая же ситуация в некоторых странах Центральной Азии (например, Афганистан) и Африки (Нигерия).

Может иметь значение и размер абонентской базы — процессы небольшого и федерального провайдера строятся по-разному.

Все это значит, что создать систему, которая бы удовлетворяла все возможные «хотелки» заказчиков, невозможно. Но можно предсказать направления, в которых будущие пользователи могут захотеть доработать продукт.

Если это сделать еще на этапе проектирования, вы избежите множества проблем. При этом вовсе не обязательно реализовывать все заложенные в архитектуре возможности — важно чтобы потом их можно было внедрить малой кровью и без «костылей».

Главный секрет того, как избежать таких ошибок, прост — нужно серьезно проанализировать предметную область, прежде чем предпринять какие-то действия. К примеру, мы в «Латере» в случае необходимости каких-то крупных доработок тратим до 20% времени на общение с клиентами, погружение в их бизнес-задачу, изучение общепринятой практики и разработку требований к функциональности. Если же ограничивать доработку только тем, что нужно конкретному заказчику, для других она будет бесполезной. А для серийного программного продукта это гарантированные убытки.

Не пытайтесь объять необъятное

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

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

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

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

Итак, слушать клиентов нужно и важно. Однако нужно критически подходить к их идеям и не бояться вносить какие-то фичи в запретный список. А затем — отказывать клиентам, которые будут просить реализовать их. Намного больше пользы будет увидеть их истинные проблемы, которые всегда растут из бизнеса, изучить опыт коллег, и сделать сразу все правильно.

Будьте готовы к многократному переписыванию кода

Качественные архитектурные решения хороши своей стабильной работой и тем, что экономят время и ресурсы на поддержку и эксплуатацию продукта. Однако в случае сложного продукта редко удается все сделать правильно сразу — наверняка какие-то элементы системы будут работать неоптимально, и с этим придется что-то делать.

Понять, где именно необходимы доработки, может быть очень нелегко. Пример такой ситуации — разработка функциональности системных событий нашего биллинга «Гидра». Под такими событиями подразумевается какое-то изменение важных параметров, которое требует от системы определенных действий — например, при снижении остатка средств на счете до нуля, абоненту следует отключить доступ к услуге. Очевидно, что событие в данном случае должно нести в себе какую-то информацию об абоненте, например его идентификатор, MAC-адрес и т.п. Все это казалось правильным и логичным на этапе проектирования, однако потом начались проблемы. К примеру, при определенном стечении обстоятельств система отрабатывала не так, как ожидалось в предметной области: кто-то поменял код услуги, а он использовался в команде на подключение доступа, должны ли пересоздаться события по всем абонентам?

Оказалось, что в реализации событий была заложена бомба замедленного действия. Код этого модуля со временем стал очень сложным, а проблема отсутствия доступа возникала постоянно, причем известно о ней становилось не сразу — события не пересоздавались, пока не происходило что-то непосредственно с этим абонентом, а когда это происходило, нужно было вызывать медиума, чтобы определить причины. Разработчики боялись дотрагиваться до этого кода, чтобы починив одно не сломать другое.

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

Заключение

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

Другие статьи по теме ИТ-инфраструктуры от команды «Латеры»:

• Будни биллингистов: Как мы готовились к деноминации в Белоруссии
• Как сделать миграцию на новый биллинг простой и понятной: автоматизируем перенос данных
• Автоматизируем учет адресов и привязок в IPoE-сетях
• Разработка приложения для повышения эффективности выездных сотрудников: Опыт Planado.ru
• Что еще влияет на инфраструктуру: Как обеспечить качество монтажа оборудования