Весь Росатом работал на Джире — и что случилось в день Х
В 2018–2019 году мы уже догадывались, что нужно какое-то импортозамещение, потому что как-то немного странно, что Росатом зависит от зарубежного вендора. Джира проникала в структуру незаметно и понемногу, и в какой-то момент оказалось, что на ней ведутся многие проекты кроме строительства АЭС и других объектов. И речь не про ИТ-проекты, а вообще про все проекты, которые у нас есть.
Пару лет мы лежали в сторону поиска аналога (которого на самом деле нет).
1 февраля 2021 году Atlassian объявил о прекращении поддержки серверной версии. Решили запланировать переезд в дата-центр, но увидели, что это такой хитрый способ поднять цену в полтора раза. Стало грустно, но аналогов на рынке всё ещё не было.
Потом был технический сбой на 2 недели. Люди за 2 недели потеряли свои данные. Стало ещё грустнее.
Потом пришло письмо счастья, что аккаунты РФ будут отключены. Но сроки не обозначили.
В общем, мы опять огляделись в поисках аналогов для проектов нашего масштаба, взяли решения нескольких вендоров для сравнения, чуть не сошли с ума от прекрасных стратегий их продажи и доработок продуктов прямо во время презентаций, плюнули и написали своё отраслевое решение. Которое ещё и предлагаем другим российским компаниям.
Что пошло не так с Джирой
Во-первых, она произведена не здесь.
Во-вторых, они поднимали цены, нарушали работу сервиса и под конец сообщили, что прекратят поддержку российских аккаунтов.
В-третьих, у них там есть пара фатальных то ли уязвимостей, то ли ставших известными бекдоров, которые существенно снижают безопасность без внешних патчей или прикрытия умными файрволами.
В-четвёртых, у нас появилась идея окуклиться в своей серверной версии в замкнутом контуре за DMZ. Вроде бы отлично, у нас есть хорошая команда поддержки, хорошая команда разработчиков, где-то костыликом подопрём, где-то в свою разработку уйдём.
А надо сказать, что к нам иногда приходят друзья и коллеги из ФСБ. Всё-таки мы Росатом, без таких друзей и коллег работать не получится. И вот они сказали, что уязвимости по их анализу там такие, что лучше всё это сразу закопать. Если кому-то интересно, они критичные уязвимости публикуют в реестре в открытом доступе: можно посмотреть актуальные известные им дыры в корпоративном ПО разных версий.
В-пятых, примерно в это же время нас поразил плагин draw.io: мы однажды заходим после обновления в Confluence, открываем очередную схему, а там пусто. Он ничего нам не сохранил.
В общем, терпеть было нельзя и надо было переходить на отечественное решение.
Отечественные решения откровенно лажали
Мы большие. В смысле, реально очень крупная компания с не менее крупными проектами. Мы хорошо документируем все проекты, потому что у нас есть собственные стандарты того, как не надо делать разработку AS IS, чтобы потом про наши объекты не снимали по два сериала на инцидент. Так вот, с такими размерами проектов никто на российском рынке просто не работал. Ну или делали вид, что работали, но по факту переварить такое количество задач и пользователей не могли.
Нам важно, чтобы и таск-трекер, и база знаний были вместе. Обычно на российском рынке либо то, либо другое. Либо криво прикрученная Вики к таск-трекеру. И это чаще всего даже не система управления проектами, программами, портфелями, а это просто таск-трекеры. Там есть задачки, есть канбан-доска, и, будет здорово, если там ещё гант окажется, вообще бинго, джекпот.
У проектов начиная от обслуживания атомных ледоколов и заканчивая разработкой роботов разные методологии. Их надо настраивать по-разному, у них разные процессы и разные автоматизации. Каждый взаимодействует со своими системами своим собственным образом.
Самая частая проблема — то, что каждый проект ведётся отдельно. Например, нет сквозного поиска между проектами, нельзя импортировать бизнес-процесс из соседнего проекта, нельзя взять какой-то объект. Банально, если вам надо собрать отчёт по проектам в Томске, у вас никогда не будет сводной статистики — у вас будет 20–30 записей отдельно, и склеивать их придётся вручную в Экселе. А нам нужно много сквозной аналитики, и мы постоянно соединяем данные с разных проектов.
Ещё у нас 15–20 тысяч задач в одном проекте, а есть проекты и по 150–200 тысяч задач. И это часто просто убивало имеющиеся системы, потому что они не могли достаточно масштабироваться, чтобы это переварить.
Поэтому часть решений не прошла этот отбор, дальше внутри системы у нас в Atlassian велись абсолютно разные проекты.
Ещё нам хотелось удобный и понятный интерфейс. Наши пользователи довольно избалованные, им нужно, чтобы было красиво, просто и понятно. Потому что внутри мы именно так и делаем. Ну, по крайней мере, стараемся. Им важна оперативность устранения ошибок, например, а не сидеть и смотреть 30 секунд, как что-то грузится.
Нам нужна была техподдержка — первая, вторая и третья линии. На пилотах мы загружали по 100–150 задач за пачку, и даже это часто роняло возможности поддержки, потому что при ошибках каждый отдельный пользователь пытался дозвониться и понять, что случилось.
Нам нужны были интеграции с огромным количеством наших корпоративных систем.
Всё это мы вынесли в техтребования, отдали российским компаниям, сгенерировали несколько тестовых проектов со случайными данными —, но с валидаторами, кастомными полями, разными наворотами, разными типами задач и так далее. Дальше мы пробовали это мигрировать из Джиры в систему вендоров, которые участвовали в предзакупочной процедуре.
Если очень коротко, выяснилось, что все системы заточены под простые типовые проекты. Где-то совершенно ужасный интерфейс с точки зрения полезности представления (например, нужно найти все задачи с меткой «срочно», захожу в поиск во всех проектах, а у меня эта метка «срочно» в каждом проекте как отдельный объект — и на выходе портянка на 50 экранов, в которой поиск идёт по каждому отдельному проекту, и просто понять, что уже горит и как, невозможно).
Ещё одна особенность — у нас кросс-проектная команда. Человек может быть на 0,25 в одном проекте и на 0,75 в другом, иметь разные роли и так далее. Нужны сквозные функции для управления всем этим.
У кого-то была ужасная поддержка: например, мы при миграции репортили ошибки со скриншотами, а нам даже не отвечали, что взяли их в работу. Я на своём опыте боюсь даже представить, что случится, если мы не будем отвечать нашим пользователям или если бы мы им отвечали так же долго, как некоторые.
Ну и вишенкой на торте стали скрытые платежи. Некоторые решения нам всё же понравились, и вендоры обещали их доработать. Ок, доходим до коммерческого предложения, а там система делится на модули. И нам в базовом расчёте в конкурсе дали два базовых с обрезанным функционалом. Начинаем считать полный, а там ещё 2 нолика приписались. И так плюс-минус везде, начинаем получать детализацию — выясняется, что надо доплатить за каждый чих. Кто-то не мог предоставить техподдержку: например, нужно учитывать часовой пояс. Или формально техподержка есть, но не более 10 запросов в месяц — остальное за дополнительную плату. В одном из коммерческих предложений у нас были пересечения только на 2–3 часа в рабочее время с некоторыми филиалами, и это не давало полноценно пользоваться поддержкой. Вендор считал такую ситуацию нормальной.
Или вот история. Как-то к нам пришли разработчики, провели демонстрацию, мы посмотрели их систему. Говорим, по функционалу очень сильно отстаёт, очень долго доделывать, наверное, не подходит. Вроде бы мирно разошлись. Через какое-то время мне присылают ссылку на телеграм-канал, где этот чудесный разработчик анонсирует, что они чуть ли не внедряют свою систему в одной ОЧЕНЬ БОЛЬШОЙ компании, которая занимается атомной промышленностью, но название они говорить не могут. Ну да, у нас же в стране очень много таких компаний. А потом смотрим на их сайт, а там уже наш логотип, уже наше название в качестве заказчиков. Мы, конечно, привлекли юристов, этот вопрос решился достаточно оперативно.
В результате длительного конкурса в качестве победителя был выбран null.
В общем, рынок нас опечалил. Ничего такого, что хотелось бы внедрять, не было.
«Ну напишите сами тогда, если такие умные»
Собственно, оценивая затраты на доработку того, что было, и собственную разработку, внезапно выяснилось, что если у нас будет ядро системы, то всё остальное окупится. То есть если бы нашлись опенсорсные решения с подходящими лицензиями, которые можно было бы форкнуть и дорабатывать у нас, — это было бы прекрасно с точки зрения рациональности проекта.
Они нашлись. Что удивительно, даже удалось соблюсти все условия лицензии, здесь мы очень нагрузили юридический департамент.
Основные компоненты из OpenProject, Nextcloud, OnlyOffice.
Проблем с опенсорсом две: во-первых, вы не можете выбрать стек разработки (в нашем случае это Ruby on Rails), во-вторых, потом всё то, что вы соберёте, надо как-то сертифицировать у ФСТЭК.
С рельсами проблема в том, что в какой-то момент все разработчики куда-то делись. Но мы посмотрели по рынку и выяснили, что явление почему-то было временным и сейчас они то ли вернулись, то ли появились ещё откуда-то. Рынок наполнился специалистами снова.
ФСТЭК же фактически фиксирует ядро в каком-то статичном состоянии, и если вы хотите внести апдейт, нужно проходить сертификацию заново.
Мы форкнули OpenProject, но участвуем в сообществе, мы официальные community member, имеем возможность сами заводить задачи, выполнять задачи других участников. Как мои разработчики смеются, что это очень странно работать на госкорпорацию и коммитить в опенсорс. Мы не обрубили все концы по обновлениям, время от времени смотрим, что хорошо дружит с нашей версией, и втягиваем.
Надо сказать, что у нас очень много кастомных требований. У Atlassian есть маркетплейс плагинов, и мы им активно пользовались. Например, был темпо-таймшипт, у нас там фиксирование трудозатрат, их планирование. Там, где плагинов не хватало, многое мы делали через скриптранер (на Groovy). Часто это были костыли. В новой системе многое из того, что обходилось костылями на скриптах, сразу же стало особенностями ядра — мы убирали мешающие ограничения. Например, банальная вещь — попробуйте быстро и просто разделить один проект на два подпроекта. Вас ждёт много интересного в стеке Atlassian.
Важно было ещё отвязать решение от окружения. Из-за импортозамещения не очень понятно, что будет завтра. Какие базы данных, какие ОС, какие браузеры. Лучше уж расширить варианты того, с чем может работать система, а то если инфраструктура сменится, пользователи будут вынуждены искать IE 6.0, чтобы вставить флешку с ЭЦП. Мы такого точно не хотим) И новых шагов миграции не хотим.
Сейчас платформа включена в реестр российского ПО (реестровая запись от 08.02.2024 № 21435).
Миграция
Дальше встал вопрос миграции. Мигрировали мы в новую систему постепенно. Не нужно приходить в понедельник утром, брать рубильник, отключать всё и говорить: «Добро пожаловать!»
Никому не понравится, правда.
Так долго растягивали миграцию по простой причине, потому что для каждого проекта выбирали удобное время. Это какой-то релиз, окончание спринта, это помогло нам разгрузить нашу техническую поддержку и тренеров, которые проводили обучение сотрудников. В план миграции мы за эти полгода безостановочно, без единого дня простоя, без единой потерянной точечки перенесли всю информацию уже в свою систему.
Всем советую, прошло на удивление гладко.
Мы обычно переносили те данные, которые есть на текущий момент, например, в начале спринта, и потихонечку обучали команду на этих данных в течение пары-тройки недель, пока шёл спринт. А потом уже команда привыкала, что нужно сюда кликнуть, вот здесь посмотреть, что это вот так оказывается работает и это даже прикольнее чем было. Потом мы довносили в систему только ту дельту, которая произошла за эти 2–3 недели. Конечно, это вызывает нагрузку на поддержку, год мы поддерживали сразу две системы. Но сейчас полегче, потому что Джира и Конфа уже выведены из эксплуатации.
В итоге перенесли больше 2 тысяч проектов, более 50 тысяч активных задач и в целом больше 200 тысяч задач, которые не в фазе работы.
Конечно, пользователи не очень любят что-то новое, да никто особо что-то новое не любит. Это нужно заново привыкать, адаптироваться, подстраиваться. С одной стороны, жалоб у нас было меньше нормального количества, потому что пользователи знали, что вариантов выбора у них ровно два: либо документы от руки, либо новая система. Никто не настаивал, но поскольку есть много связанных проектов, вручную документы готовил бы целый отдел. Кто-то поначалу пробовал вести учёт задач и документацию в офисных пакетах, но довольно быстро они поняли, что лучше уж разобраться с новой системой.
Второй важный аспект — мы собрали для пользователей комьюнити. Это такая штука, куда сотрудники могут заходить и задавать вопросы, общаться между собой, предлагать новые функции. Можно голосовать за приоритет задач в беклоге. Функции с наибольшим количеством голосов попадают в следующий релиз автоматически.
И тут случилось чудо. Пользователи стали бороться не с системой, а за свои доработки. Появилось сарафанное радио, появилась политика, и, самое интересное, что те, кто голосовал за функции, считали их своими. И рассказывали про них коллегам. «Смотрите, смотрите, там в системе моя функция, я сделал, сейчас будет так удобно, так здорово, я вам всё покажу, ещё и вас научу этим пользоваться». В общем, мы стали руками для проектных руководителей.
Особенности решения
Третьей важной частью задачи была возможность вынуть данные из системы. Элементарно для бекапа или миграции. Какие бы вы ни выбрали пути, которыми вы хотите пойти, всегда нужно иметь с собой маленький чёрный чемоданчик, который вы в любой момент возьмёте и из этой системы раз и навсегда уйдёте. Да и бекапы должны быть в читаемом формате.
Кстати, если вы когда-нибудь пробовали смотреть бекапы Atlassian, то с радостью сообщу, что они читаются только продуктами Atlassian. И если вам заблокировали аккаунт, то развернуть вы его можете примерно нигде. У одного из внешних заказчиков сертификат безопасности просрочился, и они на 2 недели вывались из работы и потеряли свои данные. Очень повезло, что мы им тогда делали тестовую миграцию, они прибежали и: «Вот то, что вы перенесли, можно мы используем дальше в работе?» — и мы им конвертировали их же бекап. Если что, там у людей были госзакупки, контракты, деньги, горели сроки — и такие эксцессы могут вызвать глобальные задержки.
Благодаря комьюнити мы увидели, как люди согласовывают документы перед сдачей проекта в эксплуатацию. Вообще в Atlassian есть плагин, позволяющий работать с офисным пакетом документов вместе, но он не прошёл нашу безопасность. И оказалось, что раньше в Confluence люди шарили экран на видеоконференции и вместе правили. Медленно и печально. Мы им прикрутили удобный мультиплеер в модуле для работы с документами, и теперь они видят курсоры друг друга и очень радуются. Сразу скажу, что стандартные решения не всегда подходят, потому что если вы когда-нибудь загоняли в 100-страничный документ 25 человек, каждое действие которых меняет разбивку на страницы, то примерно понимаете, о каком аде может идти речь. А ещё ведь надо делать нормальную историю версий и возможность работать с каждой правкой.
Потом нам понадобился хороший поиск. Поиск должен осуществляться не только в темах и описании задач, но в кастомных полях, комментариях, внутри документов, в теме документов, везде, в совещаниях. Потому что иногда пользователи приходят и говорят: «У меня была какая-то задача или документ, но я не уверен. Даже не знаю в каком конкретно проекте» — надо, чтобы он нашёл по тому, что помнит.
Сделали много независимых настроек для каждого проекта. Хотите спринты, канбаны, хотите водопады, хотите ещё что-то. Любые подходы. Это помогло нам внутрь системы привлечь те направления, которые раньше про Джиру даже не знали и не думали туда заходить.
Очень хорошо получилось с совещаниями. Старый стандартный процесс был такой: ставим встречу в календарь через почту, туда пишем повестку в Джире. Во время встречи можно прям отмечать галочками прогресс по повестке. Мы эту систему расширили, потому что раньше пользователи искали, что было на совещании, в почте. Теперь мы прямо из Атом.Проекта даём возможность создать встречу с повесткой, к задаче крепить совещания и сразу смотреть, что на них было. Можно сделать срез — какие у нас были совещания по этому проекту. Ага, вот списочек, вот об этом договорились, вот такие задачи созданы, вот сейчас они в таком состоянии, а вот тут надо обсудить, но ещё не обсудили.
Как попробовать
Мы можем дать демодоступ. ПО серверное, устанавливается в прод-версии на серверах заказчика, может устанавливаться и работать в закрытом контуре без доступа в интернет. Это потому что мы госкорпорация, нам в облако нельзя. Из коробки есть в том числе интеграция с GitLab и GitHub.
У нас сейчас есть демонстрационный контур, он вынесен вовне и доступен из интернета. На наших мощностях работать не даём, потому что мы за безопасность. Всем спокойнее спится, если ваши данные хранятся у вас. Ну и несмотря на то, что система разработана в госкорпорации, есть партнёры, через которых мы без огромного количества бумаг работаем.
