Загляни за кулисы разработки nela nms: inventory.Zator

Пока готовится очередной релиз (третий по счету) нашего инструмента nela: invZ приглашаем тебя заглянуть за кулису разработки. Мы позиционируем nela: invZ как инструмент для освобождения твоего рабочего времени. Это означает, что наш инструмент исправно выполняет за тебя всю работу, связанную с инвентаризацией сети, учетом активного сетевого оборудования и резервному копированию файлов настройки.

nela nms by network-lab.ru

nela nms by network-lab.ru

Инструмент уже готов и активно используется участниками network-lab и нашими клиентами. Мы хотим, чтобы число людей, которые разумно используют свое время, росло, поэтому мы постоянно работаем над улучшением этого продукта. Улучшения заключаются в добавлении новых возможностей, исправлении багов и упрощением его использования. В этой статье мы рассмотрим доработку программы, которая затрагивает добавление новой возможности и упрощения использования. Что же такого мы хотим добавить и как мы это делаем?

Как гласят мудрые книги по управлению, например библиотека ITIL: чтобы что-то улучшить, надо определить желаемый результат (поставить цель) и что-то регулярно измерять. Это совершенно необходимо, чтобы понимать, что процесс идет в верном направлении. Кроме того, в ITIL есть замечательная методика, которая описывает процесс постоянного совершенствования услуги (CSI – Continual Service Improvement), основанная на Цикле Дёминга . Цикл Дёминга – классическая модель управления (производством, процессом, да чем угодно), которая состоит из 4 шагов Планирование (Plan), Действие (Do), Оценка результатов (Check) и Корректировка и массовое внедрение (Act).В ITIL этот цикл взят за основу и на его основе построен цикл из шагов:

ITIL F / Continual Service Improvement

ITIL F / Continual Service Improvement

В процессе разработки nela: invZ мы пришли, что следование этому циклу сильно упрощает работу, повышает ее эффективность и сокращает время. Поэтому создание части релиза будет тесно связано с этим процессом.

Для нас предметом для улучшения стало указание IP-адресов для сбора информации с активного сетевого оборудования. Конкретная цель с точки зрения нового функционала:

1) возможность задавать диапазон IP адресов любого размера;

2) размер диапазона IP адресов можно определять маской или префиксом.

Сети бывают разные

Сети бывают разные

Конкретная цель с точки зрения упрощения использования:

1) убрать строгий порядок следования пары «IP адреса, чистка базы»;

2) возможность указывать маску подсети либо префикс, кому что привычнее;

3) передавать параметры в виде «ключ-значение», для упрощения визуального восприятия запуска программы nela: invZ.

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

1) Что: задание диапазона IP-адресов парой ключей: IP-address/mask Как: задаем ключи-параметры нашей программе, она производит вычисления и выводит нам перечень IP-адресов, проверяем результат вывода. Ожидаемый результат: диапазон совпадает с тем, что мы посчитали на листике J

Эталон расчета IP адресов

Эталон расчета IP адресов

2) Что: задание диапазона IP-адресов парой ключей: IP-address/prefix Как: аналогично пункту 1. Ожидаемый результат: аналогичный пункту 1

3) Что: специфические случаи диапазонов IP-адресов (префикс /32 – один хост и префикс /31 – подсеть для линков точка-точка (point-to-point link)). Как: аналогично пункту 1 (нам не нужны специальные ключи, все должно быть просто). Ожидаемый результат: аналогичный пункту 1

4) Что: последовательность передачи ключей. Как: задаем пары ключи-параметры,  Ожидаемый результат: диапазон всегда один и тот же без влияния следования: «IP-address/prefix», «prefix/IP-address», «IP-address/mask», «mask/IP-address»

5) Продолжаем создавать нужные нам тесты, с учетом пары ключ-параметр для флага очистки базы.

Уверены: общую суть ты уловил. Чем больше у тебя таких прописанных сценариев тестирования, тем больше шансов на успех, хорошую программу и реализацию без багов. Наши индикаторы (KPI)-  не количественные, а качественные: работает или нет.

У нас уже есть конкретные цели и показатели, на которые мы ориентируемся. Следующим шагом мы определяем нашу текущую точку, то место где мы сейчас находимся, что мы хотим изменить. Возможно, изменения и не нужны (чистое предположение). Вот как выглядит текущий запуск нашей программы (детально изложено в этой статье: network-lab.ru/instrument-dlya-inventarizatsii-seti-nela-nms-inventory-zator-nela-invz-reliz-0-1-1/):

./invZ011.pl ip cl

Где IP адрес представляется в формате:

1) 10.10.10.10 (то есть IP-адрес конкретного узла)

2) 10.10.10.* (адрес подсети из 254 узлов)

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

Относительно ключа очистки базы: он принимает 2 значения (очищать базу или добавлять записи) – этого достаточно. Тут улучшение затронет только придание осмысленности значению «Y» и «N».

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

Текущая реализация алгоритма

Текущая реализация алгоритма

Вот как будет выглядеть алгоритм (укрупнено) по обработке ключей, который мы хотим создать:

Планируемая реализация алгоритма

Планируемая реализация алгоритма

Да, общего у нас не так, чтобы и много. Фактически – только получение информации от пользователя.

Итак, подготовительный этап у нас завершен. Теперь у нас есть четкая картина, что нам надо делать, как это делать и сколько мы на это потратим. На этом этапе мы делаем корректировку бюджету времени, который мы устанавливали ранее. Точность здесь будет приближаться к 95%.

После этого начинаем сам процесс разработки улучшения для нашей программы nela: invZ.

Perl in progress...

Perl in progress…

Важный момент, пока саму программу мы не изменяем. Мы пишем отдельную программу, которая должна осуществлять задачу по обработке пар ключ-значение и вычислению диапазона IP-адресов. И тут еще интересный момент всплывает: на самом деле, мы логично разбить на этом этапе данную задачу на 2:

1) Вычисление диапазона адресов

2) Считывание и корректную обработку пар ключ-значение

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

Только сейчас мы пришли к написанию самого кода нашего инструмента. Процесс написания связан с постоянной отладкой, поиском багов и т.д. Чем точнее ты поставишь задание, тем проще будет написать код и меньше времени будет на тестирование. Например, мы забыли учесть специальные ситуации (длинны префиксов /31 и /32). В итоге потратили немало времени уже на поиск бага в почти готовом проекте. Это сейчас мы уже записали это в начальные тесты, так сказать, задним умом.

Когда тестирование завершено, мы добрались уже до 6 пункта нашего процесса по ITIL кругу. Мы оцениваем, что нам надо для интеграции в саму программу nela: invZ. То есть мы уже находимся на взлетной полосе. Что у нас есть: две написанные подпрограммы, которые отлажены и работают хорошо. Первая программа получает в аргументах IP-адрес подсети, маску (или префикс), и ключ, который показывает, что мы используем: маску или префикс. Выглядит вот так:

./i1 10.10.2.0 23 –pr
List of IP addresses:
10.10.2.1
10.10.2.2
10.10.2.3

10.10.3.254

Вторая программа считывает данные из аргумента, распознает их и сохраняет :

./i2 –ip 10.10.10.0 –pr 23
Pairs key value are following:
‘-ip’ => ‘10.10.2.1’
‘-pr’ => ‘23’

Осталось все собрать воедино, для этого надо ответить на простые вопросы:

1) Как мы будем это делать? (Какой порядок действий?)

2) Что делать, если что-то пошло не так? (Варианты отката и общей отладки?)

3) Сколько мы потратим на это времени?

В случае нашего улучшения обе подпрограммы писал один и тот же человек, поэтому этим пункты были отвечены в устной беседе. Если бы работало несколько человек, конечно лучше было бы этот момент формализовать хотя бы в виде MoM (Minutes of Meeting).

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

Проделана хорошая работа, можно немного отдохнуть и  переходить к планированию нового улучшения.

Relax

Relax

P.S. Интересно получилось, когда мы начинали писать статью, то целью ставили для себя просто познакомить тебя с тем, как мы разрабатываем свой софт и решаем отдельные задачи, чтобы ты тратил меньше времени на работу. С нашей программой nela: invZ это возможно. А получилась статья из разряда «ITIL и мы». Может и хорошо, что так получилось: знания не бывают ненужными.


Комментарии:

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Hide me
Получать регулярно свежие материалы, лабораторные и вебинары
Email Имя
Show me