Дорогой дневничок... (производственникам посвящается)

Проработал в сфере ИТ почти 15 лет. В крупной энергетической компании.
По результатам своей работы чуть не сошел с ума от того насколько у нас все печально...

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

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

Люди, работаевшие в больших коллективах, наверняка сразу вспомнили одного–двух (а может и больше) таких коллег.
И я часто встречался с мнением, что руководство "все прекрасно понимает", но ему (руководству) просто похуй.
Это опасное заблуждение, хоть иногда это и может быть правдой.
На самом деле руководитель это человек, который не обязан вникать во ВСЕ детали работы своих подчиненных + у него своей головной боли хватает. Руководитель зачастую опирается на мнение своих авторитетных подчиненных. Тех, кого он СЧИТАЕТ авторитетными.

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

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

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


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

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

Через некоторое количество секунд вы оказываетесь на высоте, на которой положено открывать парашют. Дергаете за кольцо.... и НИЧЕГО!....Ничего не происходит, нет у вас парашюта над вами, который должен вас спасать от смертельного удара об землю.

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

Так вот в данном примере само наличие второго парашюта и есть "Отказоустойчивость". Отсутствие отказоустойчивости — 1 парашют. Отсутствие устойчивости к отказу одного единственного критически важного элемента.

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

Телеметрия.
На своей старой работе я отвечал в том числе и за каналы передачи данных — Телеметрии.
Телеметрия это показатели работы чего–либо. Если вы лежите на больничной койке и к вам подключены аппараты снимающие кровяное давление и частоту ударов сердца — это тоже телеметрия (удары и давление), телеметрия вашего организма. Данные со счетчиков, которые вы передаете в управляющую компанию (электричество, вода, газ) — тоже телеметрия... Причем тут телеметрия станет понятно чуть позже, это описание определения простым языком для незнающих, чтобы потом было понятнее.
На любом производстве этой телеметрии очень много. Она важна, и что самое важное — она не должна "отваливаться" просто так.

DMZ
ДеМилитаризованная Зона. Не путать с DMZ, которые пихают в домашние роутеры. Там (в домашних роутерах) так зачем–то у многих производителей принято называть "переадресацию всех портов на указанный адрес".
Для общего понимания что это и зачем опишу последовательно в порядке возрастания размеров несколько гипотетических компьютерных сетей компаний.

Пример 1 (очень маленькая компания):
Некоторое количество компьютеров, которым нужен только исходящий доступ в интернет. Т.е. компьютеры сами выходят в интернет (сайты, внешняя почта и т.п), но никаких входящих подключений извне в сеть компании не подразумевается.
В такой сети DMZ не нужен.

Пример 2 (средняя компания):
Помимо исходящего доступа, есть еще и доступ извне. Например подключения сотрудников из дома через VPN, входящие подключения на ваш внутренний почтовый сервер, на свой внутренний веб–сервер (сайт компании, который крутится на собственных мощностях внутри вашей сети).

Тут уже нужен DMZ.
Отдельная от основного контура сеть, со своими усиленными политиками безопасности.
Зачем — для того чтобы оградить основную сеть (в которую подключены компьютеры персонала, принтеры и прочая сетевая инфраструктура) от сети, потенциально подверженной сетевым угрозам. Любые открытые для доступа извне ресурсы потенциальная цель для атак. Причем не только хакеров, целенаправленно атакующих вашу компанию, так и автоматизированных атак, направленных на эксплуатацию уязвимостей в вашем ПО, которое либо просто забыли обновить, либо не успели (бывают еще веселые варианты, когда НЕЛЬЗЯ обновлять, потому что "не безопасно"), ну или просто нет обновления закрывающего такую общеизвестную до автоматизации уязвимость. Причем последнее встречается очень часто... не только потому что ПО старое, а зачастую еще и потому что а) может быть самописное с использованием внешних компонентов (уязвимость в компоненте, который программист просто прикрутил не думая) и б) программист тупо не в состоянии переписать код на что–то новое.

Так вот... DMZ это специальная сеть, за которой служба ИБ (или просто инженеры, в зависимости от компании) следят внимательнее, чем за обычной сетью, где настроены более суровые политики безопасности и мониторинг. Доступ в обе стороны (DMZ–> внутрення сеть и Интернет –> DMZ) контролируется брандмаурами (сетевыми экранами) с жесткими ограничениями куда, кому и по какому поводу можно подключаться.

Пример 3 (крупная компания):
По сути как пример 2, НО DMZ может быть не только между интернетом и внутренней сетью, но и между сегментами внутренней сети.

Собственно пример безалаберного проектирования:

Я отвечал за прием телеметрии в нашем сегменте сети с серверов в DMZ другого сегмента.
И сервер этот, в DMZ другого сегмента, был всего один.

К чему это приводило:
Как только на том, единственном, сервере что–то случалось, пропадали данные.
Куча инженеров со всех сторон начинале в ужасе это все чинить, а потом порой РУКАМИ вписывая данные с датчиков в таблицы. А данных там ой как много...на каждом объекте. 1 параметр в секунду по 10–50 датчикам. Ремонт этого единственного сервера в отдельных случаях мог занимать по несколько часов. Рекорд по–моему 9 часов. Попробуйте на калькуляторе посчитать сколько данных нужно руками пойти и снять с датчиков и потом вбить их в табличку.

И вот... возвращаясь к примеру с парашютом. Был бы это не один сервер, а 2 (серьезная отказоустойчивость это минимум 3) — данные бы даже не пропадали. И не было бы беготни с "СРОЧНО ПОЧИНИТЬ" и последующих пыток сотрудников переписыванием данных вручную.

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

Ну и есть "два", которое чуть сложнее описуемо.
Как–то раз я присутствовал на совещании с обсуждением такого проектного решения (планирование). И вот в какой–то момент обсуждения представители нашей компании начали требовать объяснений "А зачем?" на вполне себе правильный и необходимый нам самим элемент этого проекта.
Т.е. подрядчик не поленился и предложил что–то дельное, а с нашей стороны прозвучал посыл вроде "сначала докажите что нам это надо...".
Я даже не знаю как правильно завершить эту мысль, насчет "два", так что вот вам анекдот про такую ситуацию:

А: — Подскажите как правильно поступить? Я в этом ничего не понимаю, вы специалист, я вам верю.
Б: — Надо делать вот так...
А: — Я не согласен!

Еще один пример. На этот раз безответственного отношения к своей работе.
По этой же самой телеметрии, в нашей компании имелись серьезные проблемы с качеством (данные постоянно терялись, даже если с самими серверами все нормально было).
Так вот после длительного изучения вопроса, я пришел к заключению что дело в одном старом, прогнившем уже от старости, протоколе (стандарт — OPC DA) передачи данных, который:
— перестал соответствовать современным требованиям еще в начале нулевых.
— никогда вообще не соответствовал требованиям тех сетей, где мы его применяли.
— намертво прибит (праварен) к ОС семейства Windows. (А в нашей стране много где велено уходить с Windows во всяких критически важных местах)
— имеет новую итерацию, лишенную всех недостатков первой (OPC DA), в т.ч. привязку к Windows + имеет море бонусов сверх.

Так вот, собрал я все эти данные и стал пытаться общаться с людьми, ответственными за эту самую телеметрию и ее "благополучие".
8 месяцев и одно письмо на имя директора потребовалось чтобы "ответственные" люди вообще задумались о вопросе. "У нас есть письмо, где вы за все отвечаете, делайте чтобы на старом все работало" — вот примерно такая позиция вдалбливалась мне в мозг с той стороны много месяцев подряд.

Собственно к чему я это все?

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

Если вы простой инженер — обращайте внимание на критику, как бы сильно вы не считали что вы правы. Как бы сильно вы ни были уверены в том что все сделали правильно и тем более "всегда работало...". Последнее (всегда работало) в ИТ неприменимо. ИТ постоянно меняется и развивается. Если бы люди жили по этому принципу (всегда работало) — мы бы были в каменном веке. И это не только про ИТ.

Для руководителей — Как бы это ни было "НЕ К ВАМ" или "НЕ ВАША ЗАДАЧА", в критически важных моментах ИТ можно хоть немного, но разобрать основы, понять для себя что и как работает хотя бы примерно. Тем более руководитель на то и руководитель, что может пригласить к себе инженера и попросить на пальцах объяснить тот или иной принцип, на основе которого работает что–то важное в компании. И скажу вам честно — очень мало вещей в ИТ, которые прям крайне сложно на пальцах объяснить, если ты знаешь как это работает сам (в смысле если инженер знает).

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

Телеметрия — OPC UA. Универсальный протокол передачи телеметрии. Поддерживает шифрование, авторизацию, ДОСЫЛ потерянных данных в рамках настроенного буфера.

Аутентификация/авторизация — OpenID Connect. Современный протокол аутентификации\авторизации. Безопасен, прост как 3 копейки, есть несколько Российских серитфицированных (!) реализаций. Многие "западные" решения это на самом деле и есть перекрашенный OpenID Connect. Примеры OpenID Connect решений — Google Account, Apple.ID, Инстаграм, Microsoft Azure, Okta и прочие. Сбер.ID, Яндекс.ID и прочее — тоже этот самый OIDC. Причем OIDC поддерживает невероятно простую федерацию. Т.е. при наличии интеграции с OIDC, можно в 10 минут настроить федерацию с тем же яндексом и пускать к себе пользователей по учеткам яндекса или того же вк. Захотели кого–то пригласить на собеседование и ему надо зарегистрироваться? Пусть просто войдет под своей учеткой вк на ваш гостевой сервер...

Несколько специфическое... диски на виртуализации — VVOL на VMWare и для кубернетеса забыл честно говоря как называется... В общем если вы энтерпрайз с крупным парком серваков, ВМВарой и сетевыми дисками (полками), но у вас не vvol — все очень плохо.

Написал korn3r на d3.ru / комментировать