Домашнее задание №8 (Лисичкин Дмитрий)

case-study.md

@@ -0,0 +1,67 @@
+# О моих проектах
+
+В настоящий момент я отвечаю за большой Rails-монолит (~350k cloc).
+Проект является внутренним сервисом производственной компании, активное развитие проекта началось более 10 лет назад.
+Сервис покрывает сразу несколько классов задач, но основное направление связано с хранением и версированием конструкторской документации.
+
+Второй проект с которым я недолко связан - это некоммерческий блог на базе headless CMS ghost (JavaScript).
+
+## Rails-монолит
+
+### Плюсы и минусы внутреннего сервиса.
+
+Основным плюсом внутреннего сервиса явлсяется то что у нас очень ограничен список возможных клиентов.
+На нашем предприятии это как правило desktop-версия firefox, у большинства сотрудников широкоформатные мониторы с высоким разрешением.
+Наш сервис развернут на внутренних серверах компании с гигабитной сетью, поэтому у нас практически не стоит вопрос об оптимизации на уровне
+сети.
+
+Основным недостатком является то что без внешних клиентов очень сложно объективно рассчитать бюджеты на основные метрики производительности.
+Кроме того существенным недостатком является то что даже на крупном предприятии нагрузка на сервис относительно небольшая,
+а в нерабочее время нагрузки и вовсе практически нулевая. Данный недостаток проявляется как сложность в оценке производительности из-за
+недостатка статистических данных.
+
+### Состояние сервиса на момент начала курса
+
+На момент начала курса я уже продолжительное время занимался вопросом производительности, поэтому основа у меня уже была готова,
+имелся мониторинг нагрузки на виртуальных машинах, подключен Sentry в качестве APM и сборщика ошибок. Несколько лет назад до
+перехода на Sentry для слежения за производительностью мы применяли APM на базе Elastic и Kibana, поэтому уже имели предстваления об основных
+проблемных местах. Уже была приобретена книга The Complete Guide to Rails Performance и проведены первые шаги по предложенному чеклисту.
+Производительность некоторых действий довольно низкая (таймаут на вормирование ответа выставлен в 5 минут), при этом среднее время полной загрузки
+страницы составляет чуть менее 2 секунд (при остуствии альтернатив пользователи могут довольно долго терпеть).
+Фронт древний, реализован на базе jquery.
+
+### Основные сложности оптимизации
+
+Большинство основных страниц системы представляют что-то вроде дашборда, отображение многих данных зависят от прав доступа пользователей,
+поэтому на них достаточно сложно производить кэширование.
+В нашем случае мы ещё и ограничены в использовании внешних сервисов, поэтому не можем использовать такие штуки как ScoutAPM или NewRelic.
+Одной из основных сложностей связанных с отсутствием доступа к этим сервисов является то, что нет удобного способа для сбора статистики о
+потреблении памяти (ни sentry ни elk apm этого пока не умеют).
+
+### Основное достижение в рамках курса
+
+Считаю основным плюсом разработку собственного инструмента для произведения последовательных оптимизаций https://github.com/Tab10id/perfolab.
+Несмотря на сырость инструмента я даже в таком виде смог дать задачу на оптимизацию одному из младших программистов, который за 3 итерации
+смог оптимизировать работу скрипта синхронизации пользователей из ActiveDirectory с 2 часов до 15 минут (помимо самих пользователей в 
+скрипте осуществлялось обновление прав доступа к внутренним репозиториям).
+
+Помимо этого хочу добавить несколько слов о системе мониторинга Sentry (хоть о ней и не было сказано в рамках курса).
+В последних версиях появился очень хороший механизм отображения основных точек роста, теперь не нужно тратить много времени на исследование,
+Sentry сам подстказывает наиболее проблемные sql-запросы, вьюхи которые рендерятся слишком много времени и т.п.
+
+## Блог на базе headless CMS Ghost
+
+Я только недавно занялся этим проектом, поэтому не могу написать много подробностей.
+Основная проблема сейчас состоит в том что на проекте нет и не предполагается никакого механизма APM,
+а мониторинг ограничивается данными о нагрузке на операционную систему на базе хостинга.
+Со стороны пользователей имеются жалобы о том, что при написании больших статей ответ системы может происходить только через несколько минут.
+Без мониторинга довольно сложно что-то предположить причину, поэтому пришлось полезть в исходники движка.
+
+Вся система движка настолько модульная, что ядро представляет из себя простое node-приложение предоставляющее REST API.
+Админка для написания статей и веб-морда это отдельные приложения которые при необходимости можно чем-то заменить.
+Когда полез в код ядра, приятно был удивлён что там уже была реализована базовая пока недокументированная интеграция с
+Sentry (но только для сбора ошибок), прикрутить туда трассировку не представляет большой сложности, поэтому я планирую в ближайшее время
+оформить соответствующий pull-request.
+
+Так же как и в случае с предыдущим проектом имеется сложность с рассчётами бюджетов, но уже по причине того, что проект некоммерческий,
+приходится ориентироваться только на лучшие практики.