Что такое High-Level Design

HLDHigh-Level Design описывает предлагаемое решение на уровне архитектуры, не вдаваясь в подробности спецификаций, конфигураций и т.п. Верно будет дать определение HLD как концепту.

HLD входит в “стандартный” набор документации, но зачем же нужно тратить время и деньги на документирование того что “впринципе и так понятно”?

В ходе подготовки и согласования HLD Заказчик приводит видение Исполнителя в соответствие своим потребностям.

Исполнитель, в свою очередь, уточняет объем, сроки и стоимость работ – эта информация необходима для управления проектом.

Таким образом, наличие “правильного” HLD снижает риски проекта для обеих сторон.

Теперь, когда понятно что такое и зачем нужен HLD, перейдем к конкретике, а именно ответам на вопросы, которые мне задают.

Кто отвечает за HLD и кто принимает участие в разработке?

Мнения на этот счет могут быть разными, мое таково: качество может быть достигнуто тогда, когда отвечает кто-то один, а не группа людей. Ответственным лицом за HLD разумно назначить эксперта по продукту / pre-sale (называть его можно как угодно).

Со стороны Исполнителя pre-sale (предлагаю остановится на этом термине как на наиболее точном определении позиции) может и должен привлекать инженеров, которые внедряли и/или будут внедрять решение.

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

Что нужно для того, чтобы начать?

Нужно понимание темы (продукта) не только на уровне “что это” но и на уровне “зачем это”.

HLD должен опираться на результаты аудита и на ТЗ, которое должно фиксировать одну или несколько целей, соответствующих критериям SMART.

В реальности вместо допуска к аудиту вы можете получить устаревшую документацию или объяснение “на пальцах”, а вместо ТЗ набор “хотелок”.

В этом случае незаменим будет опыт выполнения подобных проектов и терпение – этап HLD может затянутся на несколько месяцев.

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

Каков объем HLD?

Объем может быть сильно разный: от одной картинки до сотни страниц описания. Как правило, будет достаточно одной общей и нескольких вспомогательных схем, а также 10-20 страниц с описанием целей и результатов внедрения.

Из чего состоит HLD?

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

Рассмотрим типовой план:

1. Вступление – представляем Заказчика и Исполнителя, коротко формируем задачу. Пример задачи – внедрение частного облака.

2. Цель – коротко и ясно формируем цель. Пример – снизить ТСО на 30% и обеспечить доступность сервисов 99,9%.

Обратите внимание, внедрение System Center или vCloud это не цель, это средство, упоминать вендора тут неуместно.

3. Описание дизайна – указываем средства (тут уже уместны Microsoft, Cisco и т.п.). Акцентируем на чем основан дизайн, а это, как правило, документация, Best Practices, практический опыт внедрения подобных проектов.

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

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

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

На каждом уровне следует рассмотреть такие показатели как: Доступность, Управляемость, Производительность, Масштабируемость, Стоимость.

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

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

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

Конечно, в Заключении нужно говорить только правду – преувеличения и притянутые показатели портят репутацию Исполнителя – снижение времени простоя на 5% в год это тоже результат, и весьма неплохой.

Да, если вы посмотрите на дизайны вендоров которые представлены в открытом доступе, вы не увидите в явном виде того о чем говорил я, но перед вендором и Исполнителем стоят совсем разные задачи.

Какова судьба HLD после завершения проекта?

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

Надеюсь озвученная информация будет полезной, а если нужна будет помощь — используйте форму на главной странице моего сайта.