S
Stitex
Защита данных

Зависимость от сервера подрядчика: как проверить

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

11 сентября 20269 минутStitex Technologies

На работающем объекте эту зависимость не видно. Пока исполнитель на связи и сервер отвечает, между «система наша» и «система у него» нет разницы: экраны те же, графики те же, кнопки нажимаются. Разница появляется в один день — когда подписка не продлена, доступ закрыт из-за спора по оплате или компании-исполнителя больше нет.

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

Когда диспетчеризация зависит от сервера подрядчика, а выглядит автономной

Автономность объекта и независимость от сервера — два разных свойства, и первое не доказывает второе. Контроллер в шкафу держит уставки сам, объект спокойно проживает обрыв канала — а всё, что нужно для продолжения жизни без исполнителя, лежит на сервере в единственном экземпляре. Обрыв это скрывает: во время обрыва сервер никуда не делся, и система ведёт себя как система, у которой временно нет связи. Разложите оба случая по строкам — станет видно, где они расходятся.

Что смотримКанал оборвался на часСервер исполнителя недоступен навсегда
Регулирование в шкафуИдёт своим ходомИдёт своим ходом
Вход в системуВернётся вместе с каналомНе вернётся: учётные записи жили там
История показанийДогонит из буфера, если он предусмотренОстаётся та, что успели выгрузить
Описание точек и настройкиЛежат на сервере, вопрос не встаётСобираются заново по шкафу и проводам
Уведомления людямСервер шлёт «связь потеряна», объект — если есть свой путьИдут, только если путь заведён не через его сервер
Переезд на другой серверНе требуетсяВозможен или нет — это и решает исход

Первая строка в обоих столбцах одинаковая — с неё и начинается неверный вывод: объект пережил обрыв, значит, переживёт и остальное. Оговорка к ней касается обеих колонок: сторожевой таймер, если он заложен в проекте, переводит установку в безопасный режим, когда верхний уровень молчит дольше положенного. На час это временная мера; при сервере, которого больше нет, объект останется в безопасном режиме, пока верхний уровень не заведут заново или таймер не перенастроят, — и это тоже кому-то придётся уметь. Остальные пять строк расходятся, и на них построены проверки ниже. Что происходит с железом в момент обрыва и почему фраза «команда не теряется» читается целиком, разобрано отдельно: работа оборудования при обрыве связи.

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

Проверка 1. Вход своей учётной записью — и кто может её закрыть

Действие. Войдите в систему со своего рабочего места под учётной записью, оформленной на вашего сотрудника. Заведите вторую — сами, не обращаясь к исполнителю. Откройте список пользователей и посмотрите, кто в нём значится администратором.

  • Сдано: у вашей стороны есть роль, которая заводит и отключает пользователей — включая учётные записи исполнителя,
  • Не сдано: вход один на всех («логин объекта»), пароль знает наладчик, а новых людей заводит только исполнитель,
  • Не сдано: ваша роль умеет смотреть, но не умеет управлять доступом.

Отдельной строкой — бумага, а не техника: на кого оформлены домен, виртуальная машина или хостинг, лицензия на программу верхнего уровня и SIM-карты в модемах. Эту строку акт приёмки не содержит, если её туда не вписать, а выясняется она в тот момент, когда платить за продление предлагают уже вам.

Проверка 2. Переезд оборудования на другой сетевой адрес

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

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

Чем меняется адрес сервераЧто это значитИсход
Экран настроек или конфигурационный файл, пароль передан вамПереезд — рядовая операция, её делает наладчик на местеСдано
Утилита исполнителя, которую он не отдаётПереезд возможен, но только его рукамиНе сдано
Адрес зашит в прошивкуАдрес меняется правкой образа, а не настройкой на объектеНе сдано
Устройство принимает только сервер со своим ключомПереезд требует ключа, а ключ выдаёт исполнительНе сдано

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

Проверка 3. Описание точек, а не картинка на экране

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

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

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

Проверка 4. Архив глубже локального буфера

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

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

  • Сдано: формат открытый, в файле есть и показания, и события, а порядок выгрузки записан в договоре,
  • Не сдано: выгрузка приходит картинками или отчётом на печать — цифры в ней видно, а считать нечем,
  • Не сдано: обещание «понадобится — выгрузим», без названного формата и без порядка.

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

Проверка 5. Чьим каналом уходят уведомления

Действие. Согласуйте имитацию аварии и доведите её до конца — до сообщения человеку. Дальше посмотрите на само сообщение: от кого оно пришло. Затем выясните, где заведён этот канал: почтовый ящик, бот, шлюз рассылки, SIM-карта в модеме.

  • Сдано: канал оформлен на вашу сторону, список получателей правит ваш администратор,
  • Не сдано: отправитель — служебный почтовый ящик исполнителя, а получателей меняет он же по заявке,
  • Не сдано: SIM-карта в модеме оформлена на исполнителя — тогда канал заканчивается вместе с его договором связи.

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

Проверка 6. Обновление прошивки без исполнителя

Действие. Попросите показать, как ставится обновление контроллера или шлюза: откуда берётся файл, чем он заливается и чем подписан. Не рассказать — показать на одном устройстве.

  • Сдано: файл обновления, средство заливки и порядок действий переданы вам, и обновление не требует обращения к серверу исполнителя,
  • Не сдано: обновление прилетает только с его сервера, а файл на руки не отдаётся,
  • Не сдано: устройство принимает только образ, подписанный ключом исполнителя, и второго пути к подписи не предусмотрено.

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

Что записать в протокол приёмки

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

  • Учётные записи: кто на вашей стороне управляет доступом, и на кого оформлены домен, лицензия, машина и SIM-карты,
  • Сетевой адрес сервера: чем он меняется в оборудовании, кто передал пароль и кто выпускает ключ подлинности,
  • Описание точек: имя файла перечня, дата выгрузки и то, что он открывается без интерфейса системы,
  • Архив: период выгрузки, формат, состав — показания и журнал событий, — и порядок последующих выгрузок,
  • Уведомления: на кого оформлен канал и кто правит список получателей,
  • Обновление прошивки: чем заливается, где лежит файл и что предусмотрено с ключом подписи.

Полезная привычка — писать в протокол не «проверено», а что именно сделали и что увидели. Строка «перевели шлюз на тестовый адрес и вернули, адрес меняется с экрана настроек» спорной трактовке не поддаётся, а «зависимость от сервера подрядчика отсутствует» — поддаётся вполне.

Как это устроено у нас

Расставание с исполнителем мы считаем штатным событием, к которому система готовится заранее, а не аварией. На вопрос «что будет, если вы исчезнете» отвечаем не заверением, а тем, что лежит у заказчика на руках: описанием того, как это устроено, написанным для инженера, который придёт после нас, и выгрузкой данных в открытом формате без нашего участия. В том же перечне стоит право продолжить с другим подрядчиком без переписывания системы заново — а шесть проверок выше как раз и показывают, чем такое право обеспечено: тем, что можно предъявить действием, или словом в переписке.

Честная оговорка: сам сервер при этом может остаться нашим, и это ничего не меняет в шести проверках выше — они проверяют не расположение сервера, а наличие выхода. Перечень, из которого взяты пункты этого раздела, открыт до подписания договора, а не составляется на сдаче: что мы делаем и что остаётся у вас.

Частые вопросы

Объект работает без связи — значит, от сервера подрядчика он не зависит?

Это разные свойства. Автономное регулирование отвечает за час без канала: сервер в это время существует, и объект его дожидается. Зависимость от сервера проверяется другим вопросом — что вы будете делать с объектом, когда этот сервер перестанет быть доступен навсегда: кто войдёт в систему, откуда возьмётся описание точек и куда переучить оборудование.

Сервер на стороне исполнителя — это само по себе плохо?

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

Как проверить, что оборудование можно перенаправить на другой сервер?

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

Приёмка уже прошла, проверок не было — что делать сейчас?

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

Испытание с отключением канала связи тогда вообще нужно?

Нужно, но оно отвечает на свой вопрос: переживёт ли объект обрыв и не появится ли дыра в истории за это время. Это про поведение оборудования, а не про то, кому принадлежит сервер и что будет, когда он исчезнет. Два испытания складываются: одно показывает, что объект доживёт до возврата канала, второе — что он доживёт до следующего исполнителя.

Пройдём шесть проверок по вашему объекту

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

Контакты

Спросите нас по теме статьи

Опишите свою ситуацию — скажем, что из этого применимо у вас, а что нет. Без обязательств.

Telegram
@StitexBot
Отвечаем
В течение рабочего дня