Хорошие разновидности моделей создания систем безопасности для команд поставки имеются также у разработанного компанией Microsoft процесса создания безопасных программных средств — Security Development Lifecycle. Некоторые аспекты этого процесса кажутся излишними, но вам нужно в нем разобраться, чтобы понять, какие из аспектов вписываются в ваш рабочий процесс.
Я полагаю, что в вопросах обеспечения безопасности важную роль может сыграть возможность дать внешнюю оценку проделанной работе. Такие действия, как тест на проникновение, проводимые внешней стороной, фактически имитируют реальные попытки взлома. Тем самым можно будет взглянуть на работу со стороны и заметить допущенные командой ошибки, которые порой из-за близости проблемы к команде ей самой не видны. Если ваша компания довольно велика, в ней может существовать специально выделенная команда, занимающаяся безопасностью информационных систем, которая может помочь в этом деле. Если такой команды у вас нет, подыщите внешних исполнителей, способных выполнить эту работу. Обратитесь к ним заранее, выясните, как они хотели бы работать и сколько дней им нужно потратить на тестирование.
Следует также определить объем проверочной работы, который требуется выполнить перед каждым выпуском. Как правило, для небольших дополнительных выпусков проводить, к примеру, полный тест на проникновение не нужно, а при больших изменениях в выпусках он может оказаться весьма кстати. Ваши потребности зависят от выбранной степени допустимого риска.
Итак, мы опять возвращаемся к основной теме книги, в которой утверждается, что наличие системы, разбитой на узкоспециализированные сервисы, дает нам множество вариантов решения проблемы. Возможность использования микросервисов не только позволяет уменьшить влияние любой отдельной бреши в системе безопасности, но и дает нам больше возможностей найти компромиссы в отношении издержек, связанных с более сложными и безопасными подходами в работе с конфиденциальными данными, и выбрать менее сложные подходы в тех случаях, когда риски оцениваются значительно ниже.
Как только вы осознаете уровни угроз для различных частей системы, вы должны приступить к осмыслению того, когда следует рассматривать вопросы обеспечения безопасности: при передаче данных, их хранении или ни в одном из этих процессов.
Наконец, вам следует осознать важность глубоко эшелонированной обороны и обеспечить постоянное внесение исправлений в используемую операционную систему. Но даже если вы считаете себя непревзойденным специалистом, не следует пытаться реализовать собственную криптографическую систему!
Если вы желаете ознакомиться с общим обзором решения проблем безопасности для приложений, создаваемых на основе использования браузера, то для начала хорошим подспорьем станет некоммерческий проект обеспечения безопасности веб-приложений Open Web Application Security Project (OWASP), в рамках которого постоянно обновляется документ, содержащий описание десяти наиболее существенных угроз безопасности, — Top 10 Security Risk, который должен стать настольным пособием для каждого разработчика. И наконец, если у вас есть желание получить более развернутое представление о криптографии, присмотритесь к вышедшей в издательстве Wiley книге Cryptography Engineering Нильса Фергюсона (Niels Ferguson), Брюса Шнайера (Bruce Schneier) и Тадаёси Коно (Tadayoshi Kohno).
Освоение мер безопасности зачастую зависит от сознательности людей и приемов их работы с нашими системами. Один еще не рассмотренный с точки зрения использования микросервисов аспект касается взаимодействия организационных структур и самих архитектур. Но, как и в вопросах обеспечения безопасности, мы увидим, что игнорирование человеческого фактора может стать весьма серьезной ошибкой.
10. Закон Конвея и проектирование систем
Пока что основной материал книги был сфокусирован на технических проблемах перехода к архитектуре с использованием узкоспециализированных сервисов. Но есть еще и организационные вопросы, которые также стоит рассмотреть. В этой главе речь пойдет о том, что вы на свой страх и риск игнорируете организационную структуру своей компании!
Наша отрасль производства еще сравнительно молода, и в ней, похоже, постоянно что-то обновляется. И лишь несколько основных законов выдержали испытание временем. Например, закон Мура, утверждающий, что плотность транзисторов в интегральных микросхемах удваивается каждые два года, оказался невероятно точен (хотя есть люди, предрекающие скорое замедление этой тенденции). На мой взгляд, гораздо полезнее в моей повседневной деятельности оказался другой закон, справедливый практически во всех областях, — это закон Конвея.
В статье Мелвина Конвея (Melvin Conway) How Do Committees Invent, опубликованной в журнале Datamation в апреле 1968 года, было замечено: «Организации, проектирующие системы (здесь имеется в виду более широкое толкование, включающее не только информационные системы), неизбежно производят конструкцию, чья структура является копией структуры взаимодействия внутри самой организации».
Зачастую это высказывание цитируется в различных формах как закон Конвея. Эрик С. Раймонд (Eric S. Raymond) дал краткое изложение этого феномена в книге The New Hacker’s Dictionary (MIT Press), заявив следующее: «Если над компилятором работают четыре группы, то вы получите компилятор, работающий в четыре прохода».
История гласит, что, когда Мелвин Конвей отправил свою статью на эту тему в журнал Harvard Business Review, редакция ее не приняла, заявив, что его утверждение ничем не подкреплено. Я же наблюдал подтверждение этой теории на практике во многих различных ситуациях настолько часто, что принял ее за истину. Но вам не нужно принимать мои слова на веру: после того как Конвей вывел эту теорию, в данной области был проделан большой объем работы. Для изучения взаимосвязанности организационной структуры и создаваемой ею системы проведен целый ряд исследований.
В исследовании Exploring the Duality Between Product and Organizational Architectures (Harvard Business School) Алан Маккормак (Alan MacCormack), Джон Руснак (John Rusnak) и Карлисс Болдуин (Carliss Baldwin) рассмотрели несколько различных программных систем, которые были приблизительно классифицированы как созданные организациями со связями, имеющими либо слабый, либо сильный характер. Думаю, что в организациях с сильными связями коммерческий продукт обычно подкрепляется четкой выверенностью целей и представлений, а организации со слабыми связями хорошо представлены распределенными сообществами, разрабатывающими продукты с открытым кодом.
Проводя исследования, в ходе которых сравнивались пары схожих продуктов от организаций каждого из этих типов, авторы пришли к выводу, что организации с менее сильными связями обычно создают системы с большей модульностью и меньшей степенью связанности, а организации с более сильными связями — программные средства, обладающие меньшей модульностью.
Компания Microsoft, изучая влияние своей организационной структуры на качество конкретного продукта, а именно Windows Vista, провела собственное эмпирическое исследование. В частности, исследователи проанализировали несколько факторов с целью определения надежности отдельно взятого компонента системы[4]. После изучения ряда показателей, включая такой часто используемый показатель качества, как сложность кода, они пришли к выводу, что показатели, связанные с организационной структурой, оказались статистически наиболее значимыми оценками.
Следовательно, у нас есть еще один пример влияния организационной структуры на характеристики системы, создаваемой данной организацией.
Наверное, идея обязательной согласованности организации и архитектуры может быть неплохо проиллюстрирована на примере Amazon и Netflix. В Amazon довольно рано начали понимать преимущества владения командами полным жизненным циклом управляемых ими систем. Там решили, что команды должны всецело распоряжаться теми системами, за которые они отвечают, управляя всем жизненным циклом этих систем. Но в Amazon также знали, что небольшие команды могут работать быстрее больших. Это привело к созданию команд, которые можно было бы накормить двумя пиццами. Это стремление к созданию небольших команд, владеющих полным жизненным циклом своих сервисов, и стало основной причиной того, что в Amazon была разработана платформа Amazon Web Services. Для обеспечения самодостаточности своих команд компании понадобилось создать соответствующий инструментарий.
Этот пример был взят на вооружение компанией Netflix и с самого начала определил формирование ее структуры вокруг небольших независимых команд, образуемых с прицелом на то, что создаваемые ими сервисы также будут независимы друг от друга. Тем самым обеспечивалась оптимизация скорости изменения архитектуры систем. Фактически в Netflix разработали организационную структуру для желаемой архитектуры создаваемых систем.
Итак, все доказательства, как анекдотические, так и эмпирические, указывают на то, что организационная структура оказывает сильное влияние на характер (и качество) создаваемых нами систем. Но как это понимание сможет нам помочь? Рассмотрим несколько различных организационных ситуаций и разберемся, какое влияние каждая из них может оказать на конструкцию систем.
Для начала рассмотрим простую единственную команду. Она отвечает за все аспекты разработки и реализации системы. И может часто организовывать узкоспециализированную связь. Представьте себе, что эта команда отвечает за один-единственный сервис, скажем сервис каталогов нашего музыкального магазина. Теперь рассмотрим внутреннее устройство сервиса: множество вызовов узкоспециализированных методов или функций. Как уже говорилось, мы стремимся к тому, чтобы сервисы создавались в результате разбиения системы на такие части, при которых темпы развития внутри сервисов были намного выше темпов развития между сервисами. Наша единственная команда, имея возможность организовывать узкоспециализированное общение, отлично сочетается с направлениями обмена данными в коде внутри сервиса.