В этой статье я бы хотел поделиться своим взглядом на разработку коммерческого ПО небольшими трудовыми коллективами.

И так, начну, пожалуй, и начну издалека. Я человек старой формации, учился как сейчас говорят «хард скилам», и посвятил учебе изрядный кусок своей жизни.

Жизнь у меня была сложная, путь школа → институт → работа преграждала масса препятствий, однако же видимо родителям удалось привить мне тягу к знаниям, за что им вечно буду благодарен. Худо бедно, в перерывах между борьбой за выживание я получал драгоценные знания, изрядную долю которых получил читая книги под свечкой.

Большая часть специалистов нашего поколения (кому сейчас 40–50 лет), воспитывалась на тех же установках, одной из которых была: «знание — сила». Долго ли коротко ли, в итоге жизнь довела меня до информационных технологий.

Когда я пришел в IT нейронные сети были в книгах по математике, а интернет был доступен через модем, программирование изучали на Спектрумах, или если повезет на 286/386 Интеле. Разумеется, начинали с ассемблера. Огромное количество энтузиастов сидело за выпуклыми мониторами ночами, занимаясь непонятным абсолютному большинству делом.

Отрасль развивалась, специалист росли вместе с ней, осваивали новые технологии, но на протяжении этого развития всегда ценилось глубокое понимание изучаемого материала и умение — это применять на практике.

То есть хорошо если программист, создающий какое‑то ПО для персональных компьютеров, с легкостью может разобраться в ассемблерном коде его программы в отладчике, и не хорошо если не может, и неприемлемо если это ПО для микроконтроллера.

Программист под микроконтроллеры изучал их архитектуру, шины, протоколы и прочее.

Шло время, технологии становились кратно сложнее, времена, когда можно/нужно было наизусть знать все регистры процессора и биты в них, ушли в прошлое. Компиляторы стали оптимизировать код лучше почти любого программиста.

Абстракции нагромождались с ускорением, росло количество библиотек на все случаи жизни.

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

Появлялись средства быстрой разработки ПО, такие как легендарный Borland Delphi, который сильно упрощал многие вещи, (правда товарищи считали меня неполноценным программистом, они то писали на C++ в Visual Studio тогда еще, наверное, 6).

Но мы всегда старались разобраться в том, что мы делаем максимально глубоко и нам доставляло удовольствие сделать что‑то необычное, интересное, что‑то новое даже если это где‑то глубоко внутри.

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

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

План был надежный как швейцарские часы — мы получим глубокие знания и уникальный опыт и станем мастерами своего дела, жизнь станет не такой тяжелой как была, и к тому же будет интересное и любимое занятие.

Кто‑то решил конвертировать свои знания и умения в благополучную жизнь, и стал создавать коммерческие продукты. Не буду приводить примеры, иначе могу вызвать войны в комментариях, однако все прекрасно знают сколько достойных коммерческих продуктов было создано российским разработчиками.

Кто‑то занялся проектами с открытым исходным кодом. И вроде бы траектория пути к успеху была более‑менее понятна, точнее та ее часть, без которой успех точно не светит, а именно:

Учеба + упорство + трудолюбие → мастерство → множество попыток и, может быть, ты ступишь на тропу, которая, может быть, приведет тебя к успеху.

Причем под успехом понимается не наличие денег, а создание какого‑то достойного продукта, а деньги подразумевались автоматический — ведь хороший продукт точно купят, ведь купят?

Однако же мир оказался совсем не такой. Продукт нужен не самый лучший, но через год, а сегодня и недорого. Основатель компании хочет получать прибыль, а не содержать сотрудников. Компания может 10 лет быть убыточной, но постоянно привлекать капитал инвесторов. Ну и сейчас к этому прибавился ИИ, а именно:

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

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

А если он будет послезавтра, то он уже не нужен, потому как завтра сделает то же самое кто‑то другой.

Мы это видим не только на рынке ПО, но и в других сферах. В телекоммуникациях сложные и дорогие решения отмирают, уступая место более простым и дешевым (привет Ethernet). Ну а теперь переходим к фабуле, что делать нам?

Разберемся в чем проблема, и где все же есть местечко для нас.

Проблема

Большой багаж глубоких специфических знаний и опыта, как ни странно, может оказаться обузой, как и «старомодное» мышление — желание разобраться в том, что ты делаешь досконально.

Одной из причин является то, что многие просто не могут переступить через свои убеждения и отдать часть когнитивной нагрузки на аутсорс ИИ, боясь утратить полное и глубокое понимание собственного продукта.

Но даже если мы станем активно использовать ИИ инструменты, мы все равно вряд ли сможем составить конкуренцию новому поколению специалистов. И это хорошо, это их мир, они строят свое будущее, (мы свое построить не сумели, по крайней мере так как задумывали).

Однако же на мой взгляд не все потеряно. Наш подход к созданию ПО (да и в целом к выполнению работы), все еще востребован в некоторых узких нишах.

В разрезе ПО это различные ответственные системы, АСУТП, системы с ограниченными ресурсами, устаревшие, но все еще работающие системы, одним словом, довольно большой круг задач, где «старомодный» подход может быть эффективнее «молодежного».

Отдельно хочу затронуть тему доступности ИИ инструментов.

Лидерами в ИИ индустрии являются буквально несколько компаний, все остальные далеко в роли догоняющих, это надо признать и понимать, что ситуация вряд ли изменится в обозримой перспективе.

Существуют риски полной потери или осложнения доступа к передовым ИИ системам, как минимум блокировки учетных записей, недоступность каких‑то передовых моделей и прочие проблемы.

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

Предвосхищая комментарии определенного толка, сразу скажу следующее:

Я не имею в виду конкретные страны и/или компании, да мне бы хотелось жить в мире, где все друг с другом сотрудничают и честно конкурируют. Но пока мы живем в тех условиях, которые складываются.

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

В этой статье я коснусь только создания ПО хотя это пока малая доля моей деятельности. Итак, большая часть моих знаний/умений/опыта так или иначе связана либо с сетями передачи данных, либо с встраиваемыми системами. Про второе я планирую написать отдельную технически наполненную статью, а тут расскажу о около сетевых вещах.

Все началось с потребности собственной компании и нескольких дружественных, в ПО для двухфакторной аутентификации, и ПО для сбора данных с оборудования, а также его мониторинга.

Во всех трех случаях сложились следующие условия:

1. ограниченный бюджет

2. необходим простой продукт, так как некому и некогда, разбираться в сложном

3. желательно сопровождать продукт — а значит хорошо в нем разбираться

4. максимально прозрачное ценообразование

Первый пункт говорит нам о том, что этим лучше не заниматься, но нам интересно поэтому мы проигнорируем здравый смысл и займемся, в надежде на то, что снова получим бесценный опыт. Но все же может с опытом получим и прибыль, по крайней мере когда‑нибудь в обозримом будущем.

Вторые два более разумные.

Рассмотрим случай разработки сенсора для системы мониторинга PRTG, для коммутаторов Huawei/FutureMatrix.

Что же сподвигло меня на создание этого сенсора? Ну прежде всего мне он нужен самому, а раз нужен мне то надо присмотреться к потенциальному рынку.

Тут придется опять немного отвлечься и упомянуть вот что:

Когда‑то давно, в 2020 году, я уже разрабатывал различное ПО для мониторинга и сбора данных с оборудования, исключительно для собственных нужд. Тогда мне пришлось создать свою SNMP библиотеку, она должна была быть мультиплатформенная, быстрая и работать с широкой гаммой оборудования. Так родилась PowerSNMPv3. За шесть лет ее существования она показала себя довольно хорошо и на базе нее было создано большое количество различных утилит и сенсоров. Разумеется, для нового сенсора использовалась именно она.

Несмотря на то, что PRTG в России и был то ограничено популярен, а сейчас и подавно, тем не менее он по‑прежнему используется, и в небольших компаниях есть даже новые инсталляции — благо его бесплатная версия на 100 сенсоров, позволяет оперативно закрыть потребность в подобном ПО в небольшой компании.

Ну и в конце концов, есть еще Казахстан, Узбекистан, Армения и много других стран, где вполне возможно подобные сенсоры будут востребованы.

Нам нужно ответить на два вопроса:

1. За что покупатель будет готов платить?

2. Какие преимущества перед бесплатным ПО или собственной разработкой?

Начнем со второго. Собственную разработку отбрасываем, наша целевая аудитория — это компании, которые выбрали PRTG вместо Zabbix а значит они уже испытывают дефицит кадров/времени.

Насчет бесплатного ПО, опять же Zabbix отбросили, остаются встроенные в PRTG средства. Тут мы предложим целую массу преимуществ, об этом ниже.

Что касается первого пункта то вот что мы сможем предложить:

1. Экономия на лицензиях PRTG. Об этом тоже ниже.

2. Хорошая документация, с примерами настройки.

3. Оптимизация опроса оборудования

4. Поддержка

Опять же, пояснения начну с последних двух пунктов. Для того чтобы минимизировать запросы к оборудованию, но не терять информацию и не перегружать процессор оборудования, нужна экспертиза и реальный опыт.

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

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

Документация — это отдельная история. Инструкция должна быть полной, понятной, включать в себя примеры использования. О ней мы еще поговорим позже.

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

Ведь внедрение ИИ позиционируется как возможность экономии на зарплатах сотрудников в том числе, почему тогда покупка ПО позволяющего делать то же самое плохая идея?

Немного деталей о продукте — немного просто потому, что эта статья не про конкретный продукт, а про методологию создания ПО традиционными способами, способного конкурировать с передовыми методами разработки.

Экономика

Допустим у потенциального покупателя в сети передачи данных используются коммутаторы Huawei или их линейка для малого бизнеса FutureMatrix. И положим это стек из двух коммутаторов, они подключены куда‑то, например двумя оптическими портами.

Мониторинг состояния таких устройств обычно включает в себя следующее:

• Температура

• Состояние вентиляторов и блоков питания

• Иногда загрузка процессора и памяти

• Состояние интерфейсов

• Неплохо было бы получать данные об уровне сигнала на оптических портах

• А также неплохо бы понимать состояние стека.

В контексте PRTG потребуется добавить по одному сенсору на каждый интерфейс, для отслеживания состояния порта. А вот с состоянием стека (стековых портов, членов стека и их ролей и прочего) можно использовать SNMP сенсор позволяющий указать нужный OID.

Но чтобы его использовать, предварительно придется использовать утилиту snmpwalk для получения нужных OID.

Ну и можно вручную создать lookup файл. Проверить допустимые пределы значений и выставить лимиты. Однако на каждый стековый порт и каждый SFP модуль, будет использоваться одна лицензия. Да и сам процесс довольно трудозатратный.

Итого для мониторинга стека из двух коммутаторов, с 4 стековыми портами и двумя оптическими аплинками, понадобится минимум 12 лицензий, (4 на стековые порты, 2 на аплинки, 2 на данные с DDM SFP модулей и по 2 для данных о температуре и состоянию вентиляторов).

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

И если у покупателя в сети 10 таких узлов, то ему потребуется добавить 120 сенсоров или купить наш сенсор и использовать 10 лицензий PRTG.

Ниже представлены реальные снимки экрана с работающей сети:

Стоимость сенсора при этом должна быть выгоднее покупки расширения лицензии на PRTG. Прочие мотивы использования стороннего сенсора:

Выше я уже упомянул что ручное добавление SNMP сенсоров с указанием OID, установкой порогов и прочего, процесс трудозатратный и не совсем коррелирует с идеологией PRTG — как простой в настройке системы.

Зачастую целесообразнее купить какое‑то подходящее решение, которое снимает часть этой работы с пользователя, разумеется, если у него адекватная стоимость.

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

Документация, она заслуживает отдельного абзаца.

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

Поэтому я документации уделяю очень много времени, стараюсь ее сделать максимально понятной и наглядной.

Например, для данного продукта, в документации имеются изображения того, как сенсор выглядит в PRTG, но сами изображения — это не снимки экрана, а созданные в векторах изображения. Зачем это нужно? Первое‑это масштабируемость без потери качества, второе это сокрытие данных с реальных сетей, а также возможность локализации изображений без реальной смены языка в системе.

Да это трудоемко, но в перспективе этот метод будет экономить время на модификацию документации.

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

Заключение

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

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

Также прошу заметить, что я ни в коей мере не отрицаю массу преимуществ при использовании ИИ в разработке ПО. Однако статья адресована тем, кто по крайней мере пока, не готов радикально поменять методы работы.

Ну и желаю успеха как тем из нас кто что‑то создает с применением ИИ, и тем, кто что‑то создает собственноручно, ведь в конечном счете мы благодарны и тем и другим, за то, что они не разрушают, а создают.