Вместе или врозь: новая идея

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

Особенности выкладки питоньих проектов

По просьбам рассказываю немного подробностей о том, как у нас сейчас всё управляется и выкладывается:

• Управление каждым сервисом находится в его команде. У сервиса свой план разработки, и с другими проектами он большую часть времени не завязан. Это означает, что у меня, как куратора технологии, нет прямого административного ресурса, чтобы жёстко назначить дату апгрейда всем. Вместо этого я оперирую восторженной рекламой, открытыми обсуждениями в рассылке, игрой на чувстве сознательности, иногда рэкетом и шантажом :-). Это, собственно, и есть самая слабая часть процесса, потому что теоретически достаточно одного сервиса, отказавшегося по какой бы то ни было причине играть по правилам, чтобы всё встало.

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

• Выкладка чего бы то ни было на кластер происходит с помощью .deb-пакетов. Установка зависимостей, раскладывание нужных файлов, какие-то произвольные инициализации — всё там. Разработчики заказывают его выкладку админам, те выкладывают. Происходит это в практически автоматическом режиме. Сложная часть — это собственно отладить и собрать пакет, это делает команда проекта на своих разработческих машинах.

• Выкладке в продакшн предшествует выкладка в так называемый "тестинг", который максимально приближен к продакшну и является последним рубежом проверки. Сама выкладка в продакшн происходит мягко, незаметно для пользователей. Фактически, после того, как команда сервиса назвала версию пакета, который может работать в новом окружении, всё остальное делается без участия разработчиков. Если, конечно, что-то не ломается в последний момент.

Комментарии

Многие написали (пример) про то, что можно жить двояко: какие-то библиотеки держать общие, какие-то — свои.

Такой компромисс — на деле то же самое, что житьё в отдельных средах. Как я упомянул, неважно, каким именно способом это реализуется. Важно решить: заставляем мы все проекты жить в одной среде или позволяем решать самим, чем пользоваться.

glader:

А вот тут я наверное что-то пропустил. В чем заключается поддержка библиотек админами? Они их допиливают? Или тестируют? Или что?

Честно говоря, я не знаю. Подозреваю, что со стороны разработчика идея о том, что "админы бесполезны" примерно так же соответствует реальности, как идея менеджера о том, что "программировать легко, разработчики просто набивают себе цену". Я исхожу из того, что работы админам хватает. Иначе бы они не стояли стеной за унификацию версий не только на одном кластере, но и вообще по всему Яндексу :-).

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

glader:

И это хорошо. Зачем тратить время на апгрейд, если он не нужен?

А вот это интересно :-). Вопрос об "обеспечении яндексовости" не стоял бы вообще, если бы все проекты вели себя в этом отношении одинаково. Но это не так. В одних проектах разработчики отдают предпочтение частым апгрейдам и рефакторингам кода, в других — реализации фич, заказанных маркетингом проекта, и апгрейдятся только по крайней необходимости.

Выражаясь очень откровенно, я не доверяю мнению отдельных команд о том, когда им надо апгрейдиться :-). Не потому что я умнее их, а потому что у меня думать об этом — основная работа, а команда проекта думает про свои фичи, а не про абстрактное "будущее платформы".

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

ogintal:

Может просто типизировать проекты. Разложить по сходности задач, собрав в пул для простоты обновления. Создать виртуальную среду для каждого пула […]

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

Впрочем, эта идея мне тоже пригодилась — подробней в конце статьи.

lrrr:

У каждого проекта должна быть своя среда, а переход на новые версии библиотек можно делать административно, типа "через два месяца джанго 1.1 использовать не будем нигде".

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

Текущее видение

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

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

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

• У команд не будет инициативы апгрейдиться, пока всё "и так работает", чтобы не отвлекаться от своих прикладных задач. Поэтому они не будут получать бесплатной выгоды, которая бывает от апгрейда общей библиотеки на более эффективную версию.

• Локальные патчи к библиотекам придётся делать и поддерживать для всех версий, которые существуют в компании.

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

Месиво версий труднее поддерживать админам, которые у нас общие на весь кластер.

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

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

Это была, пожалуй, самая большая чушь из всего, что я написал в прошлый раз :-). Желание делиться кодом нельзя привить политикой, оно либо само по себе есть у разработчика, либо нет. Если он срелизит что-то, что не подойдёт кому-то другому, то это будет решаться по факту: либо библиотеку сделают более совместимой, либо проект наконец проапгрейдят, либо локальные патчи наложат. Точно так, как это происходит в глобальном масштабе.

В итоге получается примерно такой набор идей для ближайшей реализации:

• Выкладку проектов нужно будет делать с использованием virtualenv, чтобы каждый проект легко и непринуждённо мог сам выбирать, какие библиотеки таскать локально, а какие использовать системно. Надо будет внимательно подумать над ресолвингом зависимостей и совмещении этого подхода с .deb-пакетами.

• Чтобы поощрять апгрейды, нужно явно использовать новые фичи в платформе. Вот пример из головы. В новой Джанге проще настраивать логирование. Но чтобы проекту был реальный смысл потратить время на переделку настроек, ему нужно получить что-то взамен. Например возможность передать заботу по настройке админам и получить какой-нибудь красивый веб-интерфейс для просмотра логов.

• Административные меры должны применяться консервативно, в тех случаях, когда у проекта реальные проблемы: незакрытая дыра в безопасности, дикая утечка памяти или перерасход ресурсов. Это бывает довольно редко.

Возможно у меня получится вытороговать для такого эксперимента отдельный кластер, на котором всё это можно будет пробовать. Делать это по живому почему-то боязно. Впрочем, я часто бываю чересчур осторожным…

Буду стараться держать в курсе!