Где взять надежный Windows?

Исповедь программиста для заложников Билла Гейтса.

«DVR бесполезно - PC-based ненадежно», - этот спор можно продлевать до бесконечности. Так сложилось исторически, что персональные компьютеры на несколько порядков мощнее других доступных процессоров. И так уж получилось, что большие возможности чаще всего плохо уживаются с надежностью. Не менее очевидно и другое: небольшие мощности микропроцессоров не обеспечивают постоянно растущих задач.

Через пару-тройку лет читающий эту статью скажет, что это обсуждение сравнимо с вопросом: менять ли пишущую машинку на компьютер или нет? Но сегодня логика вещей все еще подсказывает, что надо бы выбрать надежность, пусть и «люминивую», но надежность. Еще десять лет назад спорили, можно ли доверять компьютерам продажу авиабилетов, сопровождение самолетов, даже оформление штрафов. При всех «против» прогресс все равно шел своим путем. Господа, кто бы ни был прав, последнее слово все равно за ПК. Да и пора прекратить гнобить их за гигантоманию Windows, обычные телефоны виснут не реже.

Нет смысла заниматься демагогией, результат известен, под шумное бормотание мы все равно пойдем за более мощными технологиями. Лучше подумать, как добавить надежности PC-based системам. Чтобы не было недопонимания, некоторым эта статья может показаться заступничеством за Билла, сразу крупными буквами напишу:

ПРОГРАММ БЕЗ ОШИБОК НЕ БЫВАЕТ! И не только в Windows. Какой бы простой ни был код, на каком бы простеньком процессоре он ни выполнялся, все равно в каких-то других условиях в какой-то другой ситуации в нем проявится сбойный момент. Это закон! Можете смеяться, что Спецлаб издает такие законы.

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

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

Занимаясь этими проблемами многие годы, мы можем обнадежить, что сегодняшняя проблема надежности не мешает жить, а некоторым и зарабатывать деньги. Статистика показывает, что подавляющее число систем на ПК все-таки успешно работают, иначе бы у нас и таких как мы не было денежек на существование. И, если некоторым зарабатывать помогают не технологии, то у нас нет богатого дяди в правительстве, да и в родне тоже, у нас нет московских или питерских связей, системы GOAL продаются, потому что на них есть спрос. Но обо всем по порядку.

1. Проблема глючных компьютерных комплектующих конечно есть, но в 90% она выявляется на стадии первоначальной настройки компьютеров. Еще 9% - в первые один - два месяца работы системы. И на выходе мы имеем вполне приемлемый допустимый процент недовольных клиентов.

2. Не так страшен черт, как его малюют. Тем более что с «нечистой» тоже можно договориться. Windows отлично поддается контролю по множеству ключевых параметров. Просто этим мало кто заморачивается, ведь, как правило, компьютер включается лишь на короткую сессию, да и под рукой всегда есть кнопки Ctrl+Alt+Del. В основном только сетевым серверам и системам безопасности требуется непрерываемая многолетняя работа. Но на самом деле безотказная (почти) работа винды – это возможно. Как минимум, на столько, чтобы это не мешало жить.

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

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

На край произвести перезагрузку всей ОС или только отдельной программы.

3. Если уж вы решились таки использовать компьютер, то обычную «записывалку» типа DVR покупать нет смысла - пушка по воробьям, просто нет смысла возиться со всеми виндами и железами ради простенькой операции. К компьютеру нужна многофункциональная система с большими возможностями. Однако оттестировать огроменное число функций – задача непосильная даже для Microsoft, где работает 20 000 программистов, и весь процесс построен по науке. Вы думаете, что Билл Гейтс специально выпускает глючные продукты, чтобы подорвать мировую экономику? К сожалению, большое число проблем не диагностируется даже в самых современных лабораториях, они выявляются только на стадии реального использования клиентами. И иногда настолько сильно проявляются, что становится очевидным несостоятельность всего проекта, как стало с Вистой и другими. А главная подрывающая сила – совместимость. Неимоверно большое число компьютерных комплектующих, драйверов и программ не так-то просто протестировать на любовь друг к другу даже самой большой в мире компании.

Но мы углубились в измышлизмы. Все-таки несколько миллионов строк программного кода Спецлаба далеки от мультимиллионов Майкрософт. Надежный софт написать можно, если правильно расставить принципы, на которых строить прочное здание.
а) Главное условие надежности – это длительное время тестирования. Если разработанный алгоритм испытывается давно и на большом числе пользователей, то при отсутствии критических ошибок его можно назвать надежным.

Нельзя заявлять клиенту о надежности, если не прошло хотя бы полгода массового тестирования основополагающих процедур. Клиенту нельзя покупать программу, со дня выпуска которой не прошло и полгода! А честному производителю нельзя такую продавать без предупреждения о коротком сроке. Конечно, этот вариант предполагает работу с большим числом добровольных бэта-тестеров. И тут как повезет, не с каждым будут сотрудничать хорошие специалисты, да и вообще не всем такая идея может понравиться. Но, слава Богу, в нашей стране не без добрых людей, и, кстати сказать, СпецЛабу удалось найти их. В основном, за счет открытости политики. Мы просто перестали скрывать свои недостатки, и народ, видя, что его не дурят, потянулся. Конечно, сначала это было нелегко, психологически трудно переступить черту откровенной критики. Были те, кто пользовался открытыми данными о проблемах и строил на этом свою конкурентную войну. Но тут надо найти мужество принять нелегкое решение: или пудрить мозги или делать хороший софт.

GOALcity Pegal – это та программа, которая запущена в тестирование еще год назад. Благодаря массовости удалось разгрести почти все «грабли» (если бы написал «абсолютно все», нарушил бы Закон!). Главный успех «Пегали» – в заслуге добрых людей! Такой мощный комплекс самых современных технологий, многие их которых реализованы впервые в мире, никогда бы не стал надежным без огромного числа добровольных тестеров. Тем более что это одна из первых программ, заточенных под многопроцессорность. Получено более 20 000 всеразличных данных, как ведет себя софт на том или ином оборудовании в тех или иных условиях. Одних только бэта-версий поменялось около тысячи. По сути, на первом плане интерфейса надо бы написать огромное слово «СПАСИБО!».

б) Автоматическая система сбора информации. Обычно ошибки программы можно найти только под специальными отладчиками языков программирования, которыми способны пользоваться лишь сами программисты. Такой способ совсем не годится для массового тестирования непосвященными в математические языки людьми. Не каждый пользователь вообще может запомнить или объяснить свою последовательность действий или реакцию софта. К основной программе нужно написать еще одну не менее важную – автоматического сбора данных и статистики. Во-первых, туда надо сохранять каждое действие пользователя, во-вторых, все выполняемые в это время процессы программы, в третьих, все параметры операционной системы в динамике и данные об оборудовании (в статике :). Но и это еще не все (все мы не расскажем :). Иногда даже всех этих данных недостаточно, чтобы понять все тонкости взаимосвязей, например влияния софта от устройства бесперебойного питания на аудиоканал. Как минимум, в такой информатор нужно включить систему сбора дампов, это на сегодняшний день самый глубокий способ проникновения в «винду». Глубже только исходные тексты, которые тоже иногда необходимо доставать через многочисленных знакомых программистов Microsoft и Intel, чтобы разобраться в каком-нибудь неподдающемся модуле.

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

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

в) Другое ограничение – это отказ от глючных достопримечательностей. Каков бы ни был соблазн загнать в программу нечто модное и гламурное, нельзя идти на поводу улюлюканья «у вас этого нет». Все что на деле имеет сомнительную надежность или низкий КПД в реальных условиях, надо резать по сердцу и извиняющимся голосом объяснять «а нам это и не надо».

4. Интеграция. Она по определению не может быть быстрой. Ежедневное припаривание к себе кодов чужого глючного железа ни к чему полезному не приведет. Хотя и создаст на первых порах маркетинговый ореол идущего впереди. Беспорядочные софтверные связи – 30% всех проблем с надежностью. Как только вы сказали себе «стоп» и с каждым начали заниматься плотнее (иногда по нескольку лет), так сразу разгрузили ТП от головной боли.

Есть еще путь изолированных модулей для самых распространенных протоколов, как например, IP-камер, но все равно нужно тестировать сами IP-камеры. Сколько их всяких ни перебывало в наших руках, и самых известных марок! Пока общая оценка их глюкозащищенности на 3 с минусом. Все надо тестить, прежде чем предлагать.

5. Теперь о ЧЕЛОВЕКЕ. Надо сразу определиться, как он будет общаться с компьютером на предмет надежности. Ему требуется удобный способ получения информации. Это может быть просто лампочка над головой, светодиод у двери, телефонный звонок, SMS-сообщение, Е-mail, ICQ… Главное, чтобы этот канал контроля надежности был выбран и существовал как класс, о чем все забывают. В оповещении СИТИ есть возможность заложить большой объем информации, но это не главное. Достаточно два типа сообщения: экстренная неисправность и неисправность в рамках планируемого обслуживания. В зависимости от категории объекта каждый сам определяет критичность. Например, перекрытие обзора камеры снегом можно отнести ко второй категории, а выход из строя после многолетней работы диска - к первой. Главное, чтобы неисправность висела над человеком. Это конечно, его дело, когда ее устранять, главное, чтобы он быстро мог получить эту информацию. Поэтому надо выбирать наиболее назойливый канал. Для домоседа – лампочка, для компьютерщика – аська, для занятого человека – телефон и т.д. Можно, конечно и все вместе, но от перебора повторяющейся информации может быть отрицательный эффект. Неисправность может быть в любой технике, наша задача – быстро и надежно довести информацию об этом. А еще лучше и получить обратную реакцию, например, нажатием какой-нибудь кнопочки на двери или телефоне. Надавил клиент на тоновую клавишу своего мобильника – отстаем от него. Нет – продолжаем долбить по всем каналам.

Тут конечно лучше не переусердствовать с критицизмом. Неисправность какого-нибудь одного элемента, например, камеры, лучше заводить во вторую категорию, чтобы клиент не стал дерганным из-за обрывов проводов в ветреной местности. Кроме того, часто приходится иметь дело с самовосстанавливающейся неисправностью. Будет глупо, если клиент созреет на техобслуживание, а обслуживать будет «нечего». Логика языка «SL++» позволяет оповещать и об устранении неисправности, например при оттаивании камеры или появлении электричества.

Но оповещение о неисправности быть должно! На сегодняшний день мало кто об этом вообще задумывается. Все сводится к нерегулярной проверке техники. Зашел через месяцок, глянул. Если все работает – хорошая система!

Господа, систем без проблем не бывает! Даже если проблем нет, все равно надо иметь этот канал «из преисподние». А дальше все по накатанной. Если видеосигнал пропал, проверяем контакт, если что-то умерло, отсылаем лог сборщика информации о надежности. Не нужно думать, что такое придется делать каждый день. При заключении договоров на обслуживании мы обычно получаем сверхприбыль потому, что чаще всего ничего не ломается. И мы не требуем заключения таких договоров. Мы просто хотим людей заставить выучить фразу: Аппаратуры без сбоев не бывает. Даже, если бывает, все равно ее надо выучить! Или иметь канал связи с надежностью.

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

Но еще один придется прибавить. Даже продавая вылизанную по всем меркам программу, необходимо содержать службу технической поддержки. Как вы думаете, почему? Потому что ЗАКОН гласит: Программ без ошибок не бывает! И действительно - мы уже, как видите, совсем отошли от условностей и влегкую рассказываем все свои проблемы – уже после официального выпуска Пегали один бэта-тестер обратился с неразрешимой проблемой: одна камера не хочет работать! Сначала был шок, уже полгода как вроде все «критические» сняли, и давно тишина в эфире, а тут!.. Засада оказалась в транскрипции, программа не понимала служебные символы типа «\» в написания имени камеры. Конечно, мало кто бы вообще мог такое изобразить, все обычно пишут «Камера 1», «Вход в здание» и проч. Этот случай один может быть на сто тысяч. Но, если он возник у клиента, не пошлешь его к Гейтцу. Поэтому ТП должна дежурить и держать нос по ветру.

К сожалению, чаще ей приходится заниматься расследованием совершенно чужих проблем. Это и стороннее оборудование, различные программки, особенно антивири и дрова поддержки бесперебойников, это и неправильно организованные сети, и естественно железяки, в общем, работы для ТП хватает. Хотя, это, конечно, для нас кажется много. Если же взять «проблемную» статистику, то по «СИТИ Скифу» идет 5-15 обращений о помощи на 100 купивших. По «СИТИ Пегалю» 1-2 на сотню, по «GOALv8» «GOALv9» менее одного на сотню. По «классике» (8 и 9) все понятно, эти старички более пяти лет как вертятся и уже давно испробованы до дыр. СИТИ, хоть и подвергалась массированному тестингу, является более сложной системой по определению, тем более что большинство вопросов идет по настройке сети, а это далеко еще нетривиальный пункт в современных технологиях. По «Пегалю» стало меньше обращений по отношению к «Скифу», потому что очень многое стало самонастраиваемым и самоадаптироваемым. Тот же модуль повышения надежности винды разруливает в том числе и сторонние проблемы. В параллели теперь могут крутиться сбойные программы других фирм, откровенно буферить сетевушку или каматозить комповый порт. МПН отслеживает процессы винды и не дает возможности каким-либо образом повлиять на надежность общей среды. Если, конечно, это не касается «дров». Но проблемы драйверов, как уже говорилось, в 99,99% проявляются уже на первой стадии.

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

Опубликовано: 6 июля 2008 г.

Ключевые слова: нет

Извините, комментариев пока нет