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

Часто компании недоплачивают или переплачивают за лицензии. У крупных поставщиков программного обеспечения (таких как Microsoft, Oracle, IBM) лицензии сложные и часто меняются. Раньше с этим было проще, потому что лицензии привязывались к отдельным физическим серверам. Но с появлением многоядерных процессоров и виртуализации уже невозможно исходить из того, что на одном физическом сервере будет размещаться, например, 10 виртуальных серверов. Как в связи с этим должна измениться лицензия? И что, если сервер будет работать только в определенное время, например в общедоступном облаке? Поставщики опасаются, что им будут недоплачивать, и соответственно адаптируют лицензии.

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

Лицензии на использование операционных систем и систем управления базами данных могут быстро стать очень затратными, если вы не будете внимательны. Использовать Microsoft SQL Server для разработки ничего не стоит, но для использования этой СУБД в продакшене вам придется покупать дорогую лицензию, стоимость которой в некоторых случаях может равняться зарплате разработчиков.

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

Поставщики публичных облачных решений в некоторой степени позволяют преодолеть недостатки лицензирования. И Amazon, и Azure предлагают виртуальные серверы, в которых стоимость лицензии включена в поминутную оплату. Запуск экземпляра Windows Server EC2 будет стоить всего на несколько центов в минуту дороже, чем запуск экземпляра Linux. При этом вам не придется беспокоиться о том, нарушаете ли вы закон с точки зрения использования лицензий.

Выше мы рассматривали преимущества решений с открытым исходным кодом, такие как преимущества Linux по сравнению с Windows, MySQL/Postgres по сравнению с SQL Server и так далее. Но что, если вам нужна коммерческая поддержка – номер телефона, по которому можно позвонить, если что-то пойдет не так? К счастью, все популярные проекты с открытым исходным кодом имеют собственную экосистему, включающую различные варианты поддержки. Цены и детали услуг различаются, но найти то, что подходит вам, не составит труда.

10.4. Договор на поддержку

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

Определите все основные компоненты вашего комплекса

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

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

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

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

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

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

Ныряем в мусорные баки

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

Итоги

• Техническое задание (ТЗ) – это документ, в котором подробно описывается оказываемая услуга.

• ТЗ должно защищать интересы обеих сторон, из него каждый должен четко понимать все требования.

• Документ SLA (параметры оказания услуг) определяет ожидаемый уровень оказания сервиса.

• Он также определяет последствия в случае несоблюдения требований SLA.

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

• Оценка поставщиков похожа на процесс собеседования с кандидатами и проверку рекомендаций.

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

• Контракты на техническую поддержку являются вашей страховкой на случай необходимости обслуживания системы.

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

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

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

• Подготовили шаблон соглашения о неразглашении на случай взаимодействия с третьей стороной.

• Понимаете SLA всех сервисов, которые вы используете, и как они влияют на доступность вашей информационной системы.

• Определили SLA ваших сервисов как для внутренних, так и для внешних клиентов.

• Разработали и описали методологию оценки поставщиков.

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

• Если это необходимо – заключили договоры на поддержку основных компонентов.

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

В этой главе

• Почему документация важна

• Виды документации

• Диаграммы и рисунки как эффективное средство коммуникации

• Стратегии включения документации в текущие процессы

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

Документация похожа на тесты: ее никогда не бывает слишком много. Но сколько ее должно быть? И как узнать, когда ее достаточно?

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

Документация, если ее регулярно обновлять, не требует особого внимания. Однако, если забросить ее на долгое время, затем придется изрядно попотеть.

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

Один из моих лучших сотрудников

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