Уроки заката Sunlight Labs

Уроки заката Sunlight Labs

Несколько месяцев назад я присоединился к Sunlight Foundation в качестве старшего советника по технологиям. Кэт Даффи, которая в то время была директором Sunlight Labs, пригласила меня, чтобы помочь поддержать их усилия по программированию и оказать поддержку всей организации. Однако только через пару недель мы узнали, что Sunlight Labs полностью закрывается. За время, оставшееся до официального закрытия, мы быстро переключили внимание на сохранение наследия работы Labs за последнее десятилетие.

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

Важно отметить, что Sunlight Labs никогда не была традиционной мастерской по разработке программного обеспечения, она всегда была инкубатором, в котором культивировались интересные идеи. Ресурсы часто были ограничены, и выпуск новых инструментов и концепций был наивысшим приоритетом. Любой, кто работал в таких условиях, может подтвердить, что лучшие методы и тщательная практика часто откладываются в сторону, чтобы сосредоточиться на доставке. Многие из созданных инструментов никогда не предназначались для выпуска.

Начните с конца

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

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

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

Документация

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

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

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

Лицензирование

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

Поскольку у большого количества проектов Sunlight не было лицензий, я создал инструмент для массового добавления лицензий во все проекты, в которых их не было. Мы использовали лицензию GPLv3 для большинства из них, так как это строгая лицензия, которая требует совместного использования модификаций кода, помогая сохранить эти инструменты для использования в будущем. Однако есть много других хороших лицензий, которые следует учитывать.

Держите дом в чистоте

Одной из наиболее трудоемких задач была подготовка множества проектов для публичного размещения на GitHub. Поскольку большое количество этих проектов хранилось только на внутреннем сервере GitLab без публичного доступа, многие из них имели безопасные секреты — пароли и учетные данные API — жестко запрограммированные в источнике. Часто эти учетные данные хранились вне обычных файлов настроек, а поскольку учетные данные были разными в каждом проекте, таких инструментов, как BFG, было недостаточно, чтобы найти их все. Опять же, мне пришлось написать набор инструментов для переноса репозиториев из GitLab в GitHub, для проверки потенциально проблемных файлов и для автоматического удаления учетных данных из этих файлов. Даже после этого по-прежнему требовалось много часов ручного просмотра кода для проверки случайных учетных данных.

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

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

Выберите самое простое решение

Одной из самых больших проблем было большое количество простых «брошюрных» сайтов, которые представляли собой специальные приложения, написанные с нуля, вместо того, чтобы использовать обычное готовое решение. Сотрудникам было сложно их поддерживать и поддерживать в рабочем состоянии — часто для обновления одной страницы требовалось три разных человека. В одном случае мы потеряли весь контент сайта из-за того, что он был построен на Heroku с использованием службы базы данных, которая прекратила свое существование — нам пришлось очистить Интернет-архив, чтобы вернуть контент. Главный веб-сайт Sunlight Foundation сам по себе был одним из самых сложных приложений, созданных Лабораторией, извлекающим данные из семи различных баз данных — каждая из которых имеет совершенно разный тип (включая MySQL, PostgreSQL, Mongo, Redis, Memcache, и другие) — для доставки контента.

Поскольку у Sunlight больше не было специальной технической команды, поддерживать их работу было бы нецелесообразно. После обсуждения с остальными сотрудниками я выбрал Wordpress как простую платформу, чтобы люди могли управлять контентом в будущем. Мы выбрали WPEngine для управляемого хостинга, чтобы сотрудники могли положиться на них в решении любых технических проблем, которые могут возникнуть.

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

… Но планируйте худшее

Постоянной проблемой было то, что архитектура программного обеспечения Labs использовала отдельные огромные серверы, на которых размещались критически важные части инфраструктуры, совместно используемые всеми приложениями, почти без избыточности. Это означало, что при выходе из строя единственного DNS-сервера или сервера базы данных большинство наших приложений немедленно отказывали. Это случалось несколько раз за несколько месяцев, пока мы закрывали Лаборатории. Это также означало, что серверы постоянно недозагружались, хотя и были невероятно дорогими — ежемесячный счет AWS составлял более 6000 долларов в месяц!

Немного дополнительной избыточности может иметь большое значение. Более того, проектирование вашей архитектуры с помощью небольших «атомарных» частей может уменьшить общие зависимости и обеспечить большую стабильность. Обычно это дешевле, чем запуск огромных серверов. Запуск одного приложения на сервер — хорошее практическое правило для небольших инструментов, и вы всегда можете разделить службы (базы данных, средства запуска задач и т. д.) по мере роста ваших потребностей.

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

Последние шаги

Когда пришло время свернуть все и перенести контент, нам помогли многие партнеры. В частности, Интернет-архив невероятно помог в извлечении всего нашего контента из списка сайтов, которые мы предоставили. Их фантастический проект 301Works взял наше собственное доменное имя для сокращения URL-адресов и электронную таблицу наших ссылок, чтобы сохранить их навсегда, поэтому мы смогли полностью закрыть его (см. выше о том, как не изобретать велосипед).

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

Сложнее всего было работать с Amazon, так как нам нужно было создать образы AMI наших инстансов EC2 (очень медленный процесс с вышеупомянутыми огромными серверами), а затем предоставить доступ (по номеру учетной записи) новым владельцам. Мне никогда не удавалось предоставить доступ к корзине S3 отдельной учетной записи — устарела ли документация или была системная ошибка, я никогда не узнаю — для большинства из них я просто делал контент общедоступным, где это было возможно, и отправлял вне ссылки.

Подведение итогов

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