- PVSM.RU - https://www.pvsm.ru -
«Завтра 20-е число, а значит снова будет шторм. Остановить его невозможно, только подготовиться и надеяться, что в этот раз пронесет, случится чудо, и наш озерный паром покорит океан». Такие мысли одолевали команду, занимающуюся поддержкой портала муниципальных услуг еще несколько лет назад. Как мы попали в эту ситуацию и как мы из нее нашли выход будет рассказано ниже.
В далеких 1990-х годах область ЖКХ испытывала бум развития, внедрялись новые технологии, автоматизированные информационные системы, закупалась новая техника. Но кое-что оставалось долгое время практически без изменений, а именно платежки за квартиру. Да-да, те самые квиточки за квартиру, трансформировавшись в платежные документы, обретя штрих-коды, детальную расшифровку, оставались по-прежнему бумажками. Типовая схема работы расчетного центра предприятия ЖКХ или ресурсоснабжающего предприятия была следующей:
Постепенно модемный интернет заменялся на широкополосный доступ, возникла мысль — почему бы не получать онлайн платежные документы в электронном виде? В это же время сферу ЖКХ трясло и в организационном виде, МПП ЖКХ (муниципальное производственное предприятие жилищно-коммунального хозяйства) сменяли МУПы (муниципальные унитарные предприятия), ДЕЗы (дирекции единого заказчика). По итогам всех трансформаций произошло отчуждение ИТ-отделов предприятий ЖКХ, и на их базе родились всевозможные расчетные центры. Суть расчетных центров заключалась в, собственно, расчете квартплаты и информационном обеспечении населения.
Именно тогда родились первые информационные порталы, предоставляющие населению услуги в электронном виде. Число первых пользователей измерялось десятками, не все доверяли платежным документам в электронном виде, другие еще не слышали о новшествах, мобильные приложения в сфере госуслуг были редкостью. Работа информационных порталов не сильно отличалась от работы привычных информационных систем и, конечно, ни разу не являлась хайлоад архитектурой.
Шли годы, порталы совершенствовались, появились возможности принимать показания приборов учета, формировать справки и т.д. Именно в это время на горизонте появились первые «тучки», все больше и больше пользователей начали регистрироваться на порталах и запрашивать данные. Вдали показалась первая волна приближающихся нагрузок.
Команда (далее — Команда 1) предприняла следующие меры по оптимизации:
Несколько лет ситуация казалась стабильной, количество пользователей отдельных порталов измерялось тысячами, еще не штормило, но покачивало существенно, децентрализация расчетных центров играла на руку разработчикам.
Новой вехой в истории стало развитие портала муниципальных услуг на уровне региона. Включение единой точки входа для любого жителя республики было заманчивой идеей, дополнительно это позволило бы поднять рейтинг государственного сайта на уровень лучших коммерческих или банковских сайтов, где каждый житель региона получал бы множество различного рода услуг. Одной из самых востребованных могла стать оплата жилищно-коммунальных услуг и внесение показаний приборов учета.
Таким образом, следующим этапом стало отделение оперативной информации расчетных центров от информации, отображаемой в платежном документе. Для этого были разработаны простой формат передачи данных и база для хранения информации, проведен расчет необходимого для хранения места на 5 лет эксплуатации.
Ключевые решения, предпринятые на этом этапе:
На этом этапе решение из полноценного превратилось в бэкенд, так как портал предоставлял пользователям единый интерфейс. У портала была своя команда, которая разрабатывала его независимо от текущего решения расчетных центров. В нашей истории появляется вторая команда (далее — Команда 2) и новый вендор. Как увидим далее, это существенным образом повлияло на развитие и решение проблем. Суть проектного решения была следующей:
При проектировании БД принималось простое отображение формата в базу данных, в качестве СУБД был выбран PostgreSQL 9.3 (на тот момент вполне актуальная версия). Формат состоял из 9 плоских файлов, каждый из которых загружался командой COPY (читаем — очень быстро) в множество таблиц конкретного расчетного центра (у каждого расчетного центра был свой регистрационный номер) базы портала. В некоторых расчетных центрах количество записей, необходимых для формирования платежных документов, доходило до 1 000 000. В год это составляло до 12 000 000, за 5 лет -60 000 000. Количество запросов к данной базе увеличивалось до суммы всех пользователей районных порталов и могло составить десятки тысяч. Было, о чем задуматься.
Не имея подобного опыта, Команда 1 предприняла следующие шаги для снижения потенциальной нагрузки:
Портал был запущен, и подготовленные планы столкнулись с реальностью:
Этот момент и описан в начале поста. Сложно было диагностировать проблему, потому что проблемы казались во всех местах сразу. Команда 1 и Команда 2, одинаково любимые своим руководством, предпринимали шаги для выхода из ситуации, но общения между собой практически не было:
Команда 2 предприняла, казалось, логичный и полезный шаг: формирование платежного документа стало запрашиваться сразу после захода пользователя в систему, в расчете на то, что пока он по страницам доберется до нужного места, ПД уже сформируется, а готовый документ подтянуть можно быстро.
В это время Команда 1 каждый месяц героически решала по одной проблеме в месяц, каждый раз убеждая заказчика, что именно там скрывался корень проблемы:
Героические усилия команд приводили к локальным успехам (2-3 месяца казалось, что проблема решена). Но реальность все время подбрасывала новые вводные:
Пока шла борьба, Команда 2 настроила автоматический тест сервисов, так что о любой проблеме производительности становилось известно в считанные минуты и эскалация проблемы на самые верхние уровни управления происходила автоматически через электронную почту.
В это время в Команде 1:
Стало ясно, что с технической точки зрения решение подошло к своему пределу и пора приниматься за анализ поведения пользователей с целью оптимизации процессов или кардинальной смене технологий.
В результате анализа (тут тема для отдельной статьи) предприняли следующие действия:
Сейчас система достаточно стабильна, укладывается в регламентные сроки и требования по нефункциональным характеристикам, но на горизонте снова появились тучи:
Поэтому составляется план и подготавливается реализация следующих мер:
Казалось бы, на этом можно поставить большую оптимистичную точку. Все молодцы: и те, кто делал и те, кто сделал бы сразу лучше. Но завтра будут новые Highload проекты, новые незнакомые еще проблемы. Как к ним подготовиться сейчас, что можно предусмотреть, когда еще нет данных?
Можем ли мы превратить опыт в методологию подхода к проблемам в Highload-проектах? Как ни странно, ответ ДА, все уже придумано за нас и находится в рамках Теории ограничений Э.Голдратта (Theory of Constraint TOC). Всего 5 простых шагов:
- Найти ограничение (ограничения) системы.
- Решить, как максимально использовать ограничение (ограничения) системы.
- Подчинить все остальное этому решению.
- Расширить ограничение (ограничения) системы.
- ВНИМАНИЕ! Если за предыдущие 4 шага ограничение было устранено, вернуться к шагу 1, но не позволить инерции стать причиной возникновения ограничения системы.
Описание этой теории и суть шагов достаточно хорошо описаны в литературе в конце статьи, я же напишу свое видение в рамках текущего процесса:
Такой подход позволил бы сократить время решения на несколько лет, при минимальных затратах труда программистов. В посте указаны далеко не все возникшие проблемы и нет некоторых деталей решений, так как они не столь существенные в предлагаемом подходе.
Автор: samaksyutin
Источник [4]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/optimizatsiya/342775
Ссылки в тексте:
[1] «Цель. Процесс непрерывного совершенствования»: https://www.litres.ru/eliyahu-goldratt/cel-process-nepreryvnogo-sovershenstvovaniya/
[2] «Теория ограничений. Основные подходы, инструменты и решения»: https://www.litres.ru/dmitriy-egorov-17914/teoriya-ogranicheniy-osnovnye-podhody-instrumenty-i-r/
[3] «Теория ограничений Голдратта. Системный подход к непрерывному совершенствованию»: https://www.litres.ru/uilyam-detmer/teoriya-ogranicheniy-goldratta-sistemnyy-podhod-k-nepreryvnomu-sovershenstvovaniu-6136463/
[4] Источник: https://habr.com/ru/post/483270/?utm_source=habrahabr&utm_medium=rss&utm_campaign=483270
Нажмите здесь для печати.