У меня намечается собеседование на должность архитектора. В вакансии описана одна из первых задач.
Подскажите, пожалуйста, какие подходы здесь могут быть использованы на ваш взгляд? Возможно, сталкивались с чем-то подобным? Есть что-то себя зарекомендовавшее, а есть "ты туда не ходи, ты сюда ходи"?
1. Задача мониторинга
Разработка системы сбора и отображения телеметрии работы приложений (десктоп, но не ограничиваясь). В рамках задачи необходимо:
Проработать бизнес требования, сформулировать задачу на техническом языке. Зафиксировать сценарии работы, роли, ответственности. Согласовать с заказчиком.
Проанализировать существующие решения и технологии (в том числе, использующиеся).
Декомпозировать задачу (клиентская часть, инфраструктурная часть).
Определить состав телеметрии (набор собираемых данных), оценить нагрузку.
Определить способ хранения обработки и отображения телеметрии.
Спроектировать API клиента и способ публикации телеметрии. Спроектировать библиотеку клиента. Согласовать с заказчиком.
Сформулировать технические требования к backend’у, включая требования по нагрузке, отказоустойчивости.
[Желательно] Спроектировать backend. Определить инструменты – базы данных, систему отображения, систему оповещения, спроектировать связи между ними.
На всех этапах осуществлять контроль реализации, обеспечивать техническую поддержку и документирование.
2. Полезные материалы по архитектуре/system design
Собрал некоторые материалы по теме. В том числе из топиков этого форума. Возможно, есть еще какие-нибудь полезные. Было бы здорово, если дополните.
Может быть, что-то из списка вообще не айс по вашему мнению — не стоит читать, тратить время. Может, есть что-то супер ценное.
Как дорасти до уровня Solution Architect
«Software Architecture in Practice» by Len Bass, Paul Clements, Rick Kazman; <--- советовали на форуме
«Documenting Software Architectures» by Paul Clements, Felix Bachmann, Len Bass;
«Software Systems Architecture» by Nick Rozansk;
«Just Enough Software Architecture» by George Fairbanks;
«97 Things Every Software Architect Should Know» by Richard Monson-Haefel.
Здравствуйте, avovana, Вы писали:
A>Подскажите, пожалуйста, какие подходы здесь могут быть использованы на ваш взгляд? Возможно, сталкивались с чем-то подобным? Есть что-то себя зарекомендовавшее, а есть "ты туда не ходи, ты сюда ходи"?
Это стандартная задача, которая решалась миллион раз. Есть масса типовых решений, и я так полагаю, от соискателя ожидают, что он озвучит пару-тройку, расскажет об их достоинствах и недостатках, и обоснует свой выбор выбор одной из них.
Счастье — это Glück!
Re: Разработка системы сбора и отображения телеметрии
Здравствуйте, avovana, Вы писали:
A>Добрый день, дорогие форумчане!
A>У меня намечается собеседование на должность архитектора. В вакансии описана одна из первых задач. A>Подскажите, пожалуйста, какие подходы здесь могут быть использованы на ваш взгляд? Возможно, сталкивались с чем-то подобным? Есть что-то себя зарекомендовавшее, а есть "ты туда не ходи, ты сюда ходи"?
A>1. Задача мониторинга A>Разработка системы сбора и отображения телеметрии работы приложений (десктоп, но не ограничиваясь). В рамках задачи необходимо:
Ну можно посмотреть как это реализовано в dotnet 6, например.
Еще можно посмотреть как это Zabbix делает. Там тоже исходники открытые, наверное и описание есть.
Здравствуйте, avovana, Вы писали:
A>Подскажите, пожалуйста, какие подходы здесь могут быть использованы на ваш взгляд?
Так у вас же даже расписаны шаги в самой задаче. Это очень хороший план, с него и нужно начинать. Выяснить:
Какая специфика организации, что/для чего нужно заказчику
Кто будет смотреть на телеметрию? Сотрудники вашей организации? Сотрудники заказчика? Пользователи программы? Если есть доступ "внешних" пользователей, возникает много вопросов по разграничению доступа.
Объемы, формат данных. Логи? Метрики?
Надежность доставки. Нужно ли доставлять телеметрию надежно? Или ничего страшного, если часть данных потеряется? Насколько надежна связь?
Как часто на данные будут смотреть? Есть разница между "посмотреть раз в месяц" и "на эти данные постоянно будут смотреть операторы".
Нужны ли автоматические оповещения? Какие? Зависят ли оповещения от роли? (Т.е. оповещения для ваших разработчиков могут отличаться от оповещений, которые доставляются клиентам)
Насколько хорошо известны типы запросов/визуализаций? Другими словами, можете ли вы сказать "мы нарисуем такие-то графики и их точно будет достаточно на следующий год"? Потому что есть подход "соберем что-нибудь, что просто собрать, а потом уже будем пытаться проанализировать в соответствии с возникающими потребоностями". Я обычно склоняюсь ко второму, но это накладывает дополнительные ограничения на инструмент. Многие системы мониторинга/метрик имеют слишком ограниченные возможности запросов/визуализации.
Телеметрия делается только для одного приложения? Или есть желание распространить ее и на другие проекты? Если распространить, кто является основными заказчиками? Внешние клиенты или внутренние команды?
Когда нужно предоставить первый результат? Сколько времени можно потратить до того, как будет реализовано что-то, что можно показать.
Что умеют команды? Полезна ли телеметрия разработчикам? Интересно ли? Мотивированы ли они на реализацию или воспринимают телеметрию как прихоть заказчика?
Нагрузка и достоверность данных. Безопасность. Это в контексте "злоумышленник разобрал протокол уведомлений, начал слать много мусора, включились все уведомления и поднялась паника".
Правовое поле и compliance. Какая-нибудь HIPPA может очень повлиять на то, что можно и что нельзя передавать. Или вы оперируете в Европе в рамках GDPR. В обоих случаях может оказаться так, что логи содержат какую-то личную информацию и их "так просто" никуда нельзя отправлять.
Может еще что-то есть. Поэтому основной совет — записывайте все! Требования и критерии. Ответы бизнеса. Затем структурируйте, приоритизируйте. Полезно делать трассирование требований. Например, есть у вас "[Ctx03] Требования к анализу/визуализации не определены и могут меняться во временем". Из него может следовать "[Req05] Система хранения данных должна иметь богатый язык запросов (Ctx03)". Это Req05 потом будет использоваться для анализа существующих решений. И в случае изменения исходного требования или его приоритета можно отследить, какие выводы стали неактуальны. А в целом — много разговоров, вопросов и рутины
A>Возможно, сталкивались с чем-то подобным?
Давным давно делал. Все было просто и большинство ответов диктовалось спецификой бизнеса и приложения.
A>Есть что-то себя зарекомендовавшее, а есть "ты туда не ходи, ты сюда ходи"?
Только "нет универсальных правил" . В этом как раз прелесть работы архитектором. Запросто могут оказаться, что решение, обычно считающееся дурным тоном, является идеальным для конкретной ситуации. Часть вашей работы — объяснить всем, что решение подходит под ваш конкретный контекст (ну и убедиться в этом, не только объяснить). Желательно еще и потом отслеживать, что начальные условия не изменились радикальным образом и не нужно делать новое решение.
Например, в зависимости от требований, возможны следующие решения:
Rsync существующих логов на ваш сервер по расписанию.
Добавить агента от одной из платформ (Sumologic, Newrelic) в приложение и использовать саму платформу для доступа к данным и визуализации.
Использовать какую-нибудь базу для временных рядов (time series database), сделать к ней API и визуализатор.
Написать свою систему хранения, репликации и анализа данных.
Среди этих решений нет универсального. Каждое может быть идеальным для какой-то своей ситуации.
Re: Разработка системы сбора и отображения телеметрии
Здравствуйте, avovana, Вы писали:
A>Разработка системы сбора и отображения телеметрии работы приложений (десктоп, но не ограничиваясь). В рамках задачи необходимо:
A>Подскажите, пожалуйста, какие подходы здесь могут быть использованы на ваш взгляд? Возможно, сталкивались с чем-то подобным? Есть что-то себя зарекомендовавшее, а есть "ты туда не ходи, ты сюда ходи"?
В книге Гради Буча "Объектно-ориентированный анализ и проектирование" есть пример архитектуры системы сбора данных для метеорологической станции. Думаю, там очень много похожего на задачу телеметрии работы приложений.
