Хочу предложить немного обсудить тему сервисно-ресурсной модели и спросить о необходимости разработки инструмента для использования сервисно-ресурсной модели в проектировании, разработке и дальнейшей эксплуатации систем.
Исходная позиция: разрабатываю и эксплуатирую с коллегами онлайн-систему, которая обслуживает сотни клиентов. Наша система работает на нескольких серверах, использует несколько БД, использует очереди сообщений, внешние сервисы для отправки смс и почты. Типичная ситуация? Вполне.
Что хочу получить?
Хочу получить более прозрачную систему для охвата всей картины подшефного хозяйства, чтобы видеть узкие места, видеть зависимости одних частей системы от других, знать, что ssh на одном сервере крайне важен для «вон того маленького обработчика», который работает по ночам на другом сервере.
Зачем? Иногда требуется охватить взглядом все свое подведомственное хозяйство для получения четкой картины, увидеть направления масштабирования и узкие места. В общем, подумать об архитектуре всей системы. Понимаешь, что одни сервисы (БД, очереди сообщений) используются другими (приложения), а эти сервисы в свою очередь используются третьими. Это удобно для архитектора-разработчика при разработке и развитии системы, это удобно для эксплуатанта при эксплуатации системы.
Почему не ITSM/ITIL? Если глянуть в ITSM/ITIL, то можно там увидеть тему про сервисно-ресурсную модель. Вполне вероятно, что я не совсем компетентен рассуждать о сложностях ITSM/ITIL и внедрении оного в компаниях. Поэтому поправляйте меня, пожалуйста, если я где-то ошибаюсь, здесь и далее.
В ITSM/ITIL есть про сервисно-ресурсную модель. Но когда я начинаю читать всю эту кухню и думать о внедрении какого-либо «ентерпрайз» продукта, например: ИнфраМенеджер или ОмниТрекер, то «мой голова вай-вай». (Более того эти продукты целиком мне ни к чему, затраты на их покупку, внедрение и замену используемых в текущий момент будут ого-го, причем большая часть затрат будет не на ПО). Из всего ITSM мне надо немного — только схему зависимостей ресурсов, более того ITSM вроде как должен охватить всю организацию, я же хочу всего лишь использовать на маленьком выделенном участке в узкой области.
Далее изложу очень упрощенную версию сервисно-ресурсной модели. Почему такое упрощение? Просто пока не испытываю потребности вводить больше сущностей для понимания работы всей своей системы.
Основы и термины.
Система — сочетание всего нашего ИТ-хозяйства, которое установлено на наших серверах.
Сервис — любое приложение, будь-то веб-сервер или БД (далее приложение = сервис)
Ресурс — предоставляемая возможность сервисом для его использования из-вне сервиса.
Зависимость — связь сервиса с каким-либо ресурсом иного сервиса.
Т.е. систему можно представить как совокупность сервисов, часть из которых предоставляет ресурсы, а другая их использует.
Надо понимать, что зависимость от ресурса — это не равно потоку данных. Т.е. если наше приложение, например, зависит от сервера сообщений, то оно как принимает, так и отправляет сообщения через сервер сообщений.
Нарисуем простую схему концепта.
Например, у нас есть два хоста, на одном работает приложение node.js и сервер БД, на другом сервер PowerDNS и сервер БД. Наше приложение на node.js при создании новой учетной записи добавляет соответствующий домен 3-его уровня, занося записи в БД PowerDNS'а.
Далее можно дополнять и увеличивать количество сервисов и их зависимостей. Принцип понятен.
Инструменты
Раньше я подобные схемы рисовал в Gliffy.com. Но сейчас все чаще сталкиваюсь с необходимостью поддерживать эту схему в актуальном состоянии. Но в gliffy связи на схеме — это всего лишь соединение линии и прямоугольника. Поэтому идет поиск инструмента для хранения структуры взаимосвязей и отображения этих связей на схеме.
Вот пример моей схемы в Gliffy
Извините, пожалуйста, за качество.
Deedoo
Пока идет поиск (а я надеюсь, что вы, уважаемые читатели, в комментариях подскажете мне какие-либо инструменты, возможно, что-то подобное уже было на Хабре, да я не нашел), как прототип мы с коллегой набросали небольшое приложение deedoo. В нем мы храним информацию о хостах, сервисах, их ресурсах и зависимостях, а также строим схему зависимостей. Схема строится с использованием библиотеки Joint.js.
Проект на гитхабе: github.com/antirek/deedoo Инструкция по установке есть в репозитории. С помощью deedoo нарисована схема с PowerDNS выше.
Вот, например, как выглядят зависимости node.js приложения в веб-интерфейсе deedoo
Пока приложение Deedoo кроме рисования зависимостей больше ничего не умеет. Но еще есть идея использовать его как сервер настроек. Ведь если мы знаем, что наше произвольное приложение зависит от некоторых ресурсов, пусть оно их требует для своей работы.
Написав, что-то вроде config = serverConf('http://config.server.ru').appID('super_key').get(); мы можем получить все необходимые настройки приложения при его запуске. При отсутствии в загруженном конфиге необходимых параметров мы просто не запускаем приложение. Например, при переносе БД на другой хост нам для получения настроек приложением достаточно только перезагрузить, не так ли?
Что дальше?
Пока не знаю. С одной стороны хочется более универсально, с другой — практично. Ведь цель — это сделать развитие системы более четким, прозрачным. С одной стороны подпирает мониторинг, с другой управление конфигурациями. Т.е. к этому списку сервисов — хочется видеть их метрики работы, состояния, производительности. А еще хотелось бы нажать кнопку и обновить параметры БД, приложения и т.д.
Итак, подошли к самому ключевому моменту данной заметки: что делать дальше? Варианты:
а) таки сделать все серьезно — внедрять ITSM/ITIL, выбрав какой-либо готовый продукт? (возможно есть отличные free & open source решения? описания внедрений в интернете?)
б) развивать свой велосипед? Т.е. использовать сервис, описывающий все зависимости. А новые разрабатываемые приложения используют загрузку настроек из этого сервиса. ( Мне, в целом, нравится идея любым получения настроек любым приложением с сервера настроек, добавить группы, типы — и вообще получится здравая система, имхо. Более того получение настроек свяжет эти декларированные зависимости в deedoo с реальными приложениями, которые работают на серверах. Но может это как-то стоит делать иначе? Может быть есть уже подобные системы? )
в) иное?
В общем, все получилось немного сумбурно и смешанно, т.к. здесь есть и про разработку онлайн-системы и ее же эксплуатацию. Плюс некоторый бардак в терминологии. Поделился своими мыслями и наработками, надеюсь на конструктивную обратную связь сообщества по вопросам заметки.
Upd.
Вопросы инфраструктуры волнуют не только меня. Из интересных проектов могу отметить terraform.io (в связке с consul.io) и weave.works.
Исходная позиция: разрабатываю и эксплуатирую с коллегами онлайн-систему, которая обслуживает сотни клиентов. Наша система работает на нескольких серверах, использует несколько БД, использует очереди сообщений, внешние сервисы для отправки смс и почты. Типичная ситуация? Вполне.
Что хочу получить?
Хочу получить более прозрачную систему для охвата всей картины подшефного хозяйства, чтобы видеть узкие места, видеть зависимости одних частей системы от других, знать, что ssh на одном сервере крайне важен для «вон того маленького обработчика», который работает по ночам на другом сервере.
Зачем? Иногда требуется охватить взглядом все свое подведомственное хозяйство для получения четкой картины, увидеть направления масштабирования и узкие места. В общем, подумать об архитектуре всей системы. Понимаешь, что одни сервисы (БД, очереди сообщений) используются другими (приложения), а эти сервисы в свою очередь используются третьими. Это удобно для архитектора-разработчика при разработке и развитии системы, это удобно для эксплуатанта при эксплуатации системы.
Почему не ITSM/ITIL? Если глянуть в ITSM/ITIL, то можно там увидеть тему про сервисно-ресурсную модель. Вполне вероятно, что я не совсем компетентен рассуждать о сложностях ITSM/ITIL и внедрении оного в компаниях. Поэтому поправляйте меня, пожалуйста, если я где-то ошибаюсь, здесь и далее.
ITSM/ITIL
ITSM (IT Service Management) — подход к управлению и организации ИТ-услуг, направленный на удовлетворение потребностей бизнеса. Управление ИТ-услугами реализуется поставщиками ИТ-услуг путём использования оптимального сочетания людей, процессов и информационных технологий. (ITSM в Википедии)
ITIL (IT Infrastructure Library) — библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий. (ITIL в Википедии)
ITIL (IT Infrastructure Library) — библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий. (ITIL в Википедии)
В ITSM/ITIL есть про сервисно-ресурсную модель. Но когда я начинаю читать всю эту кухню и думать о внедрении какого-либо «ентерпрайз» продукта, например: ИнфраМенеджер или ОмниТрекер, то «мой голова вай-вай». (Более того эти продукты целиком мне ни к чему, затраты на их покупку, внедрение и замену используемых в текущий момент будут ого-го, причем большая часть затрат будет не на ПО). Из всего ITSM мне надо немного — только схему зависимостей ресурсов, более того ITSM вроде как должен охватить всю организацию, я же хочу всего лишь использовать на маленьком выделенном участке в узкой области.
Далее изложу очень упрощенную версию сервисно-ресурсной модели. Почему такое упрощение? Просто пока не испытываю потребности вводить больше сущностей для понимания работы всей своей системы.
Основы и термины.
Система — сочетание всего нашего ИТ-хозяйства, которое установлено на наших серверах.
Сервис — любое приложение, будь-то веб-сервер или БД (далее приложение = сервис)
Ресурс — предоставляемая возможность сервисом для его использования из-вне сервиса.
Зависимость — связь сервиса с каким-либо ресурсом иного сервиса.
Т.е. систему можно представить как совокупность сервисов, часть из которых предоставляет ресурсы, а другая их использует.
Надо понимать, что зависимость от ресурса — это не равно потоку данных. Т.е. если наше приложение, например, зависит от сервера сообщений, то оно как принимает, так и отправляет сообщения через сервер сообщений.
Нарисуем простую схему концепта.
Например, у нас есть два хоста, на одном работает приложение node.js и сервер БД, на другом сервер PowerDNS и сервер БД. Наше приложение на node.js при создании новой учетной записи добавляет соответствующий домен 3-его уровня, занося записи в БД PowerDNS'а.
Далее можно дополнять и увеличивать количество сервисов и их зависимостей. Принцип понятен.
Инструменты
Раньше я подобные схемы рисовал в Gliffy.com. Но сейчас все чаще сталкиваюсь с необходимостью поддерживать эту схему в актуальном состоянии. Но в gliffy связи на схеме — это всего лишь соединение линии и прямоугольника. Поэтому идет поиск инструмента для хранения структуры взаимосвязей и отображения этих связей на схеме.
Вот пример моей схемы в Gliffy
Извините, пожалуйста, за качество.
Deedoo
Пока идет поиск (а я надеюсь, что вы, уважаемые читатели, в комментариях подскажете мне какие-либо инструменты, возможно, что-то подобное уже было на Хабре, да я не нашел), как прототип мы с коллегой набросали небольшое приложение deedoo. В нем мы храним информацию о хостах, сервисах, их ресурсах и зависимостях, а также строим схему зависимостей. Схема строится с использованием библиотеки Joint.js.
Проект на гитхабе: github.com/antirek/deedoo Инструкция по установке есть в репозитории. С помощью deedoo нарисована схема с PowerDNS выше.
Вот, например, как выглядят зависимости node.js приложения в веб-интерфейсе deedoo
Пока приложение Deedoo кроме рисования зависимостей больше ничего не умеет. Но еще есть идея использовать его как сервер настроек. Ведь если мы знаем, что наше произвольное приложение зависит от некоторых ресурсов, пусть оно их требует для своей работы.
Написав, что-то вроде config = serverConf('http://config.server.ru').appID('super_key').get(); мы можем получить все необходимые настройки приложения при его запуске. При отсутствии в загруженном конфиге необходимых параметров мы просто не запускаем приложение. Например, при переносе БД на другой хост нам для получения настроек приложением достаточно только перезагрузить, не так ли?
Что дальше?
Пока не знаю. С одной стороны хочется более универсально, с другой — практично. Ведь цель — это сделать развитие системы более четким, прозрачным. С одной стороны подпирает мониторинг, с другой управление конфигурациями. Т.е. к этому списку сервисов — хочется видеть их метрики работы, состояния, производительности. А еще хотелось бы нажать кнопку и обновить параметры БД, приложения и т.д.
Итак, подошли к самому ключевому моменту данной заметки: что делать дальше? Варианты:
а) таки сделать все серьезно — внедрять ITSM/ITIL, выбрав какой-либо готовый продукт? (возможно есть отличные free & open source решения? описания внедрений в интернете?)
б) развивать свой велосипед? Т.е. использовать сервис, описывающий все зависимости. А новые разрабатываемые приложения используют загрузку настроек из этого сервиса. ( Мне, в целом, нравится идея любым получения настроек любым приложением с сервера настроек, добавить группы, типы — и вообще получится здравая система, имхо. Более того получение настроек свяжет эти декларированные зависимости в deedoo с реальными приложениями, которые работают на серверах. Но может это как-то стоит делать иначе? Может быть есть уже подобные системы? )
в) иное?
В общем, все получилось немного сумбурно и смешанно, т.к. здесь есть и про разработку онлайн-системы и ее же эксплуатацию. Плюс некоторый бардак в терминологии. Поделился своими мыслями и наработками, надеюсь на конструктивную обратную связь сообщества по вопросам заметки.
Upd.
Вопросы инфраструктуры волнуют не только меня. Из интересных проектов могу отметить terraform.io (в связке с consul.io) и weave.works.
