Хранилище знаний: легко или просто?
Автор
Александр Башкиров
База знаний — это в первую очередь внутренняя страховка. Страховка, которую компания «покупает» и поддерживает собственными силами.
Традиционная роль CMDB — хранение данных относительно конфигураций. То есть относительно элементов инфраструктуры и связях между ними.
Например, сервер с именем serv-01 имеет такую-то аппаратную, такую-то программную конфигурации; он связан через коммутатор (порт, конфигурация оборудования) с сетью, которая характеризуется определенными параметрами. В лучшем случае конфигурации будут сопровождаться конфигурационными файлами или каким-либо образом связаны с оборудованием. При этом в подавляющем большинстве случаев за бортом остается вопрос о том, как именно настраивать то или иное оборудование, что делать при нестандартных (нештатных) ситуациях. И вообще нигде не встречается информация о том, что произойдет, если при настройке заменить один параметр другим, с приведением полного перечня значений.
Меньше случаев, когда к CMDB даются какие-либо централизованные комментарии относительно того «почему так». Тому есть две причины. Первая — организационная. CMDB в общем и не рассматривают как средство хранения комментариев и связанной с конфигурацией информации. Вторая — техническая. Многие CMDB не позволяют делать какие-либо комментарии в принципе.
Правда, это можно легко обойти — достаточно принять, что документация есть элемент конфигурации. Тогда она размещается в CMDB, так сказать, на правах полноценного участника (в виде файлов, например). И вроде бы в данный момент наступает счастье, но, как водится, жизнь богаче наших о ней представлений. И все дело в том, что «по жизни» документация не равна знанию. Документация — это описание особенностей продукта, организации эксплуатации и т. д. А знание — это конкретика, основанная на документации, опыте и выполнении реальных дел. Соответственно, задача «обеспечить документацию» по умолчанию не равна задаче «обеспечить преемственность знаний».
Небольшой пример. Маршрутизатор Cisco имеет отличную документацию, но для осуществления конкретного задания (включить/выключить порт, поднять/опустить VLAN) нужна инструкция с последовательностью определенных действий. Зачем? Да затем, что изучение документации может занять неограниченно долгое время, тогда как по инструкции указанная проблема решается в 5 минут. Как говорится, почувствуйте разницу.
Следовательно, для того, чтобы в полной мере обеспечить рабочий процесс, необходимо не просто создать базу данных конфигураций, но и поддерживать и актуализировать практику использования тех или иных конфигураций и настроек применительно к разным случаям. То есть создать базу знаний.
Теперь о процессах
Как водится, никакая система (даже самая идеальная) не работает сама по себе. И более того, ни одна действующая система не является идеальной. В полной мере это относится и к базам знаний. Во-первых, и в основном — базу знаний надо поддерживать в актуальном состоянии. Что далеко не такая простая задача, как может показаться на первый взгляд. Допустим, кто-то внес изменения в конфигурацию той или иной системы, но не отразил сделанного в базе знаний. Получается ситуация, при которой сама база становится ведомой по отношению к изменениям, происходящим в ней. Во-вторых, первичное наполнение базы знаний тоже представляет собой больше отдельную задачу, чье решение зачастую весьма нетривиально.
Признаться, приведенный выше пример достаточно примитивен. Обычно все складывается несколько иначе: есть база знаний, есть регламент работы с ней и есть масса точек, где возникают новые знания. И это совсем не обязательно могут быть конфигурационные файлы, а просто, скажем, новые инструкции, регламентирующие ту или иную область деятельности, прайс-листы... — да что угодно. Главное, чтобы так или иначе относилось к деятельности предприятия. Причем «что угодно» может оказаться любой сложности. Как с точки зрения техники (в том числе совершенно разнородно представленные данные), так и с точки зрения организации — зачастую из-за того, что четко не очерчены границы, на которые распространяется влияние базы знаний, случаются разные коллизии. Она может содержать неструктурированную информацию или ряд «информационных бомб» — то есть статьи и разделы, взаимно противоречащие друг другу. А это уже проблема.
Вывод из всего сказанного простой: база знаний не хранилище типа большой файловой (или информационной) помойки, куда сливается все ненужное, а инструмент, который при должном к нему внимании способен стать очень хорошим подспорьем для бизнеса.
Кстати, о подспорье. Не задумывались, а в чем оно может выражаться? Зачем вообще нужны базы знаний? Что в них такого, из-за чего они постоянно на слуху? Ответ на поставленные вопросы прост. База знаний — это в первую очередь внутренняя страховка. Страховка, которую компания «покупает» и поддерживает собственными силами. Страховка, как правило, направленная на решение нескольких задач, а именно на повышение качества обслуживания, сохранение сведений о связях тех или иных объектов и преемственности информации. Рассмотрим эти аспекты более подробно.
Повышение качества обслуживания достигается за счет комбинации единообразно размещенной информации и средств быстрого доступа к ней. В качестве примера возьмем большую телекоммуникационную компанию. Предположим, в смену выходит около пятидесяти операторов, занятых работой с клиентами. Их всех нужно обеспечить как минимум одной и той же информацией, иметь единую точку управления такой информацией. А кроме того, необходимы соответствующие регламенты — то есть свод правил, в которых бы предусматривалось, как обслуживать клиентов, что им говорить, как начинать беседу, как заканчивать и т. д. Вся эта информация может (и должна) находится в базе знаний, а также содержать справочные статьи по технологиям и ссылки на внешние ресурсы, где абоненты получат дополнительные сведения.
Второй аспект — сохранение преемственности информации. В том же центре обслуживания абонентов наверняка есть определенная текучка (к сожалению, это специфика подобных подразделений). Увы, текучка — штука заразная и способна затронуть в том числе технический персонал. Тех, кто обслуживает инфраструктуру, обеспечивает деятельность и т. д. Кстати, специфика их знаний — не только знания относительно конфигурации, но и того, «как все устроено»: как приходят телефонные вызовы, как распределяются, где и как телефонная станция интегрируется с программным обеспечением, что нужно сделать в том или ином случае... Вся это должно быть определено в базе знаний, структурировано, выстроено так, чтобы в любой момент быть под рукой. Как видим, в данном разрезе задача существенно шире «классической» CMDB. Я бы даже сказал, что получается вообще не CMDB (что и требовалось доказать).
Ну и наконец, аспект хранения сведений о связях тех или иных объектов больше всего похож на «классическую» CMDB. Правда, есть одно «но»: в отличие от CMDB база знаний хранит не только конфигурации, но и данные об их применимости, версионности, содержит заметки, описывающие оптимальные использования конфигураций, методы безопасного применения и т. д. То есть база знаний — понятие намного более широкое, чем CMDB.
Просто о сложном: поиск
Хорошая база знаний — это не только универсальное, отлаженное, исправно работающее хранилище знаний, вокруг которого выстроены правильные процессы. Хорошая база знаний — это, в числе прочего, поиск и интерфейс. Про интерфейс говорить не интересно — он просто должен быть удобным и ненавязчивым (почти невыполнимые требования, а потому их касаться не нужно — рамки статьи не позволяют). А вот на механизмах поиска следует остановиться особо. Дело в том, что любая уважающая себя база знаний должна обладать как минимум двумя взаимодополняющими механизмами поиска — по рубрикам и по контексту.
Поиск по рубрикам самый простой. Фактически речь идет о том, что каждая статья (запись) в базе знаний соотносится с одной или несколькими рубриками. Таким образом, открывая ту или иную рубрику, пользователь получает перечень статей, по тем или иным критериям сужает этот перечень и, в конце концов, получает требуемую запись. Если она есть, конечно.
Поиск по контексту сложнее и предполагает поиск, основанный не на рубрикаторе, а на содержимом записей базы знаний. Механизмов тут может быть море — от простого поиска по вхождению слова (самый «некрасивый» способ, да и достоверность его относительно невысока, зато чрезвычайно легкий в реализации) до семантического поиска (наиболее сложный для алгоритмизации и реализации способ, однако дающий очень точный результат при выполнении ряда условий, таких как наличие семантических словарей, описывающих ту или иную область). Причем семантический поиск может быть скоррелирован, например, с рубриками — хорошие базы знаний позволяют вести поиск внутри той или иной рубрики или их набора. Это если говорить о «технике» базы знаний.
Если же говорить об операторе базы знаний, то ему вообще все равно — как именно технически ищет база. Ему важно, чтобы на заданный вопрос база знаний выдала максимально достоверный ответ с максимально возможной скоростью в максимально удобном виде. Все остальное — неважно. Увы, зачастую разработчики баз знаний просто забывают про пользователя, или же строят его модель в виде киборга, который способен читать информацию из сотни мест экрана, ориентироваться в запутанном и мутном меню и черпать вдохновение в статьях, вообще не соответствующих изначальному запросу. Впрочем, все далеко не так. И потому зачастую базы знаний оснащают механизмами «самообучения» — когда пользователи со специальными привилегиями имеют возможность добавлять либо запрещать какие-то статьи применительно к тем или иным поисковым запросам. Скажем так: иногда это даже помогает. Если не мешает — ведь добавление или удаление какой-либо статьи из выдачи должно осуществляться с учетом интересов всех пользователей. О чем нередко забывают.
Процессы наполнения
Следующее, о чем нужно обязательно сказать, — ввод базы знаний в эксплуатацию. Представьте себе: на некоем предприятии, в центре обработки телефонных обращений, внедряется база знаний. Поставили серверную часть, клиентскую... и — ничего. Ничего, потому что базу знаний надо наполнять, как это не банально. И следить за актуализацией. Хотя, в общем, ничего неразрешимого в описанной ситуации нет. Достаточно сделать первый шаг — силами нескольких выделенных сотрудников наполнить базу по тому или иному направлению. Правда, следующий вопрос лежит уже в области управления. А именно необходимо обеспечить работу с базой. Ввести ее в строй. И это всегда — управленческое решение, причем, как и всегда при запуске нового продукта, приходится продираться через тернии. Да, через тот самый пресловутый консерватизм конечных пользователей. Вообще говоря, внешне победить его довольно легко — достаточно лишь перекрыть иные информационные источники. Однако, перекрывая их, нужно быть готовым принять последствия таких действий: от дружного «это неудобно» до не менее дружного бойкота. И к этому надо быть готовым, более того — с этим надо работать. Объяснять, рассказывать, показывать... Кстати, не исключено, что уже на данном этапе будут выявлены действительно серьезные баги, способные препятствовать нормальной работе, причем вне зависимости от того, насколько хорошо база была оттестирована перед вводом в эксплуатацию (специфика данного класса ПО такова, что глубокая кастомизация требуется практически в каждом конкретном случае).
Как еще заставить пользователей работать с базой знаний? Можно пойти другим путем — заранее рассказать, как это круто, сформировать ожидания... Как показывает практика, хорошо «подогретые» пользователи принимают на ура и достаточно сырой продукт, лишь бы он выполнял некие нужные им функции. База знаний тут не исключение — если она позволяет в том или ином виде облегчить жизнь пользователя, то она будет принята, даже с недочетами.
В заключение хочу остановиться на одном распространенном мифе, который состоит в том, что база знаний — вещь, изначально вторичная по отношению к «взрослым» системам. Это не так. База знаний может и должна нести определенную нагрузку в смысле бизнес-процессов. И, будучи правильно позиционированной, она превращается в инструмент, который позволит более эффективно выстроить работу. А что еще надо от любого продукта мира ИТ миру бизнеса?
Опубликовано 02.12.2013