Настоящий CTO: думай как технический директор - Алан Уильямсон - Страница 71

будут определены связи между таблицами. Вы можете дополнить эту схему комментариями, поясняющими бизнес-логику, которая стоит за структурой данных. Также все современные СУБД поддерживают возможность добавления комментариев к таблицам и столбцам наподобие того, как это делается в исходном коде.

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

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

11.2.11. Соответствие нормативным требованиям

Вы можете работать в отрасли, где требуется наличие определенной документации, например описание процессов, результаты аудитов и периодические отчеты. Типичный пример таких отраслей – здравоохранение и финансы. Некоторые правительственные и военные проекты также требуют определенного уровня описания процессов (например, соответствия стандарту ISO).

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

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

Соответствие требованиям – это, конечно, больше, чем просто документация, и все, что вы описали, необходимо выполнять на практике. Это может потребовать доработки кода или архитектуры, так что смотрите на это как на возможность для оптимизации и приведения в порядок различных частей проекта.

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

11.2.12. Учет лицензий и результатов аудитов

Вопрос, о котором обычно не думают, но рано или поздно он возникает, – как найти все ваши лицензии и купленное ПО. Заведите в базе знаний документ для учета всего используемого вами стороннего ПО, как купленного, так и с открытым исходным кодом. Сообщите команде, что важно вносить туда все, даже то, что кажется незначительным. Каждый раз, когда разработчик Java добавляет новую библиотеку в конфигурацию Maven или разработчик JavaScript подключает новый модуль npm, обновляйте этот документ, включая информацию об источнике ПО и условиях лицензии.

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

11.3. Документы для публикации (whitepapers)

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

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

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

• Принципы безопасности API.

• Рекомендации по работе с данными.

• Рекомендуемые методы работы при интеграции API.

• Жизненный цикл данных.

11.4. Рекомендации

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

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

• Создайте шаблоны, чтобы можно было быстро добавлять новые страницы. Гораздо проще редактировать что-то, чем создавать с нуля.

• Начинайте с малого и двигайтесь не спеша. Это марафон, а не спринт.

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

• Быстро создать контент можно, записав видео или скринкаст.

• Описывайте, что делает исходный код, во время его ревью.

• Отрабатывайте и тренируйте все процессы управления вашим комплексом.

Итоги

• Записывайте знания сразу, пока они еще свежи.

• Выбор правильного инструмента облегчит всем внесение изменений и дополнений.

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

• Видеоролики, голосовые заметки и схемы отлично подходят для описания деталей.

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

• Даже краткие заметки или списки – это лучше, чем ничего.

Проверьте себя

Что из перечисленного ниже вы уже сделали?

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

• Создали документ, объясняющий, как запустить и поддерживать в рабочем состоянии вашу информационную систему.

• Перечислили все компоненты вашей системы, включая сведения о необходимых версиях/лицензиях.

• Разработали простую для понимания схему архитектуры.

• Подробно описали этапы создания резервных копий и восстановления из них.

• Поощряете культуру открытости и обмена знаниями.

12. Безопасность

В этой главе

• Важные соображения по обеспечению безопасности

• Безопасная разработка ПО

• Кризисное управление при атаке или взломе

• Когда необходим CISO (руководитель направления информационной безопасности)

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

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

Заметки с полей

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

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