Глава 4. Next step
Глава 4. Next step
Russia. Examples.
Опять милый моему сердцу Лесной район Тверской области. Лес там – всему голова, это основа благосостояния жителей райцентра и окрестных деревень. Лесопилки и различные деревообрабатывающие комбинатики – вот единственная жизнеспособная промышленность, способная там прокормить народ. Бревна, срубы, доски, вагонка, летние дачные домики – все это затем отвозится на продажу в Москву, а иногда даже и в Финляндию – она сравнительно недалеко. Бензопила, острый, как бритва, топор, стамески, долото и всякие другие столярные премудрости – все это в крови у местных жителей, искусство строить избы, колодезные срубы, бани и все прочее из дерева передается из поколения в поколение. Леса вокруг много, но и вырубают его тоже по-черному. А ведь дерево – не трава, за одно лето не вырастет. Но пока еще вырубить весь лес в Лесном районе не удалось. Слишком уж много его там.
Где рубить лес – так называемые порубочные билеты – это определяет местное начальство, районная администрация – бывший райком КПСС. Есть места для рубки получше, туда и подъехать проще, и деревья там прямые и стройные, а есть и похуже – туда проехать можно лишь зимой по замерзшему зимнику и деревья там на болотине похуже, с гнильцой.
И вот один раз, в базарный день – пятницу, идем мы с местным аборигеном Юрой, помогавшим мне строить дом, по центральной базарной площади райцентра Лесное. И вдруг Юра поведал мне одну из маленьких местных хитростей.
– Вон видишь на обочине черная Волга? Это машина главы администрации.
– А зачем она здесь стоит?
– Из нее наблюдают, кто где хлеб покупает. В палатке – наш местный хлеб, он похуже и подороже. А с фургончика продают хлеб из Твери, он получше и подешевле. Но все местные стараются покупать только местный хлеб, потому что если кто-то пойдет покупать хлеб в фургончике, глава администрации его запишет и потом припомнит это, когда будут распределять порубочные билеты.
Вот с этой забавной сценкой из жизни российской глубинки у меня теперь всегда ассоциируется наукообразный термин «административный ресурс».
End of example.
– Хороший ты разработчик, но все делаешь сам, в одиночку. А если с тобой что-то случится?
Такие речи мне часто приходилось слышать от чиновников ЦБ, когда речь заходила о внедрении программы «Криптоцентр-АВИЗО». В их представлении разработка программного обеспечения обязательно должна вестись коллективно, большим колхозом, в котором есть Председатель, Правление, Партийная организация, Местком и множество иных начальников. Так привычнее, но это, как правило, система коллективной безответственности. Такие системы, наверное, хороши в каких-то иных областях деятельности, но только не в математике и программировании, где конечный результат не зависит от начальства. Не может генерал приказать программе перестать выдавать неверный код подтверждения достоверности авизо, избавить ее от «глюков». Это может сделать только программист, который писал эту программу. А сделать ему это будет тем легче, чем меньше постороннего народа совало свой нос в программу. В идеале – если все основные процедуры делал один человек, используя, может быть, только очень хорошо проверенные результаты других людей. А если большую программу одновременно пишет целый колхоз, все модули еще как следует не проверенные, с возможными ошибками, затем все это добро собирается в одну кучу – все, гиблое дело, такой программе нельзя доверять выполнение серьезных задач: непременно «заглючит», а программисты-колхозники будут до бесконечности обвинять в этом друг друга. Мне такое программирование не по душе, поэтому, по возможности, все жизненно важные процедуры в программе я стараюсь делать сам или использовать только то, что уже неоднократно испытано и чему можно доверять (но и все равно обязательно проверять!).
И вот огромный W-банк встал перед выбором: а не страшно ли связываться с программистом-одиночкой? Если бы в этом банке были одни чиновники, то наверняка вместо реальной разработки автоматизированной системы электронного документооборота получились бы бесконечные дебаты на эту тему, но тут мне опять повезло: нашелся в W-банке человек, который отмел все эти дебаты простым и понятным аргументом:
– Всю ответственность я беру на себя!
Это был Владимир Константинович Тяпкин, бывший полковник Советской Армии, инженер, кандидат технических наук.
Что же требовалось W-банку?
Первый раз, когда я появился там, мне запомнилась одна картинка. Старинное здание напротив Кремля, комнаты не то что дореволюционной, а прямо доисторической постройки, типа тех, что можно увидеть в фильме «Петр I» или «Иван Васильевич меняет профессию». Одна комната была похожа на боярскую кладовку: размером примерно 5х5 метров, но самое интересное – наклонный потолок. С одной стороны комнаты – сравнительно высокий, а с противоположной – не больше, чем метра полтора, встать и выпрямиться невозможно. Работало в этой комнате управление информатики W-банка, с одной стороны (с высоким потолком) сидела мужская часть, а с другой, где встать невозможно – в рядок три молодых девушки, которые целый день отправляли по Sprint-Net в многочисленные филиалы банка различные распоряжения, балансы, сводки, статистические отчетности и всю прочую документацию, составляющую основы жизнедеятельности любого банковского организма. И вот требовалось высвободить этих девушек, вытащить их из этой кладовки на свет божий, а всю нудную и однотипную работу переложить на автоматизированную систему защищенного электронного документооборота.
Криптоцентр позволял только шифровать и подписывать файлы, но он не был приспособлен для их рассылки. К тому же у W-банка были свои, специфические требования к рассылке: при получении адресат должен автоматически посылать отправителю подтверждение получения, заверенное своей электронной подписью. Это требование было основано на нескольких реальных случаях из жизни банка. Один раз девушка ошиблась и при отправке платежных документов по Sprint-Net указала неверный адрес получателя. Пока с этим разобрались, произошла задержка платежа и клиент выставил банку штрафные санкции. В другой раз наоборот, банк выставил по Sprint-Net клиенту по каким-то основаниям штрафные санкции, но клиент отказывался их оплачивать, впоследствии уверяя, что не получал их.
Общая причина этих и других подобных недоразумений – изобилие ручных операций при существовавшем в то время электронном документообороте, отсутствие четкого разграничения, когда и в какой момент времени ответственность за электронный документ переходит от отправителя к получателю, большая нагрузка на обслуживающий персонал, который, как и все люди, может иногда и ошибаться. И тут я еще раз смог убедиться, что криптография – это хоть и важная, но только одна составляющая в банковской системе электронного документооборота. Другая составляющая, хоть и не такая изящная, но не менее важная – электронная бюрократия, программа-чиновник.
А не получится ли так, что программа-чиновник оставит без куска хлеба человека-чиновника? Одну подобную сцену мне довелось в явном виде наблюдать в ЦБ. Первая версия программы «Криптоцентр-АВИЗО» была очень простой: девушка набирала с клавиатуры все реквизиты авизовки, программа высчитывала по ним код подтверждения достоверности и выдавала его на экран. В таком виде эта программа первоначально работала в ОПЕРУ – крупном подразделении ЦБ, где ежедневно обрабатывали несколько сотен авизовок. Под кодирование авизо была создана специальная группа, около 10 человек, но на самом деле подготовку исходящих авизо осуществляла совсем другая группа, а подготовленные пакеты авизо в виде базы данных в формате DBF передавались на дискете в группу кодирования. Здесь их распечатывали и для кодирования заново вводили в компьютер все реквизиты вручную. Когда мне впервые поведали эту таинственную Центробанковскую технологию, то я позволю себе здесь не приводить свои эмоции по этому поводу. Вскоре я принес в ОПЕРУ новую версию «Криптоцентра-АВИЗО», в которой уже был автоматический ввод всех необходимых для кодировки реквизитов из DBF-файла. Девушка – операционистка, запустив эту программу, нажала одну клавишу «ENTER» и на экране через секунду высветился результат:
Успешно закодировано авизо – 50
Первая реакция девушки:
– Ну все, теперь нас всех разгонят!
Но, странное дело, никого не разогнали. Просто вместо дурной и бестолковой работы они стали заниматься анализом баз данных, получением сводных характеристик, повышением своей компьютерной грамотности. А система «Криптоцентр-АВИЗО» тоже при этом развивалась, я все время добавлял туда по просьбе ОПЕРУ все новые и новые возможности. Одна задача оказалась достаточно нетривиальной, но в то же время жизненно очень важной.
Речь зашла о блокировке возможности повторного приема одного и того же авизо. Это был реальный случай из практики работы ЦБ и начальство потребовало срочно принять меры. Эти меры в первую очередь касались крупных РКЦ, где очень большой объем обрабатываемых авизо. Если РКЦ работало с калькулятором, то тут, опять же, оставалось надеяться только на человеческую интуицию. Но в ОПЕРУ ни одного дня с калькулятором не работали, программа «Криптоцентр-АВИЗО» там использовалась уже давно, к ней все привыкли и настало время сделать ей очередной Upgrade. Проверку на повторяемость можно было осуществить с помощью базы данных, но вся беда была в том, что при кодировании авизо по каким-то прихотям ФАПСИ категорически запрещалось пользоваться компьютерными сетями, хотя работали одновременно несколько человек на разных компьютерах. Компьютер при кодировании должен работать в автономном режиме, следовательно, об использовании общей базы данных в режиме on-line не могло быть речи. Пришлось вводить локальные системы учета для каждого рабочего места, все записи в которых в конце рабочего дня подписывались операционисткой с помощью «Криптоцентра» и затем сливались в общую базу данных, в которой и происходила проверка на повторяемость.
Но одной вещи в ОПЕРУ мне так и не удалось сделать – это избавить их от необходимости таскать дискеты из комнаты в комнату при общении с группой, которая готовит исходящие авизовки. Все были согласны: система общения должна быть автоматизирована: подготовил, зашифровал, подписал, послал по сети – принял, проверил подпись, расшифровал, использовал – все в автоматическом режиме, никаких разгуливаний с дискетами по комнатам. Но получить на это разрешение ФАПСИ – это было выше всех моих усилий! И так почти 10 лет все эти девушки своими ножками оттаптывали чиновников ФАПСИ, которым все эти проблемы были глубоко безразличны.
Но хождение из комнаты в комнату в ЦБ – это всего лишь капля в огромном океане вреда, который нанес тысячам людей чиновничий монополизм ФАПСИ. Вспомним очереди в налоговую инспекцию, регистрационную палату, во всякие обязательные фонды, живущие на деньги налогоплательщиков, но не создающие для этих налогоплательщиков никаких, даже самых элементарных удобств. Здесь же сама напрашивается автоматизированная система защищенного электронного документооборота! Вместо инспекторов – сервера, вместо поездок людей с различными бумагами – пересылка файлов по электронной почте, в зашифрованном виде и с электронной подписью. Так, глядишь, и времена настанут, когда «черного нала» и взяток поменьше будет. Технически сложно? Да, безусловно, причем не только технически, но и организационно сложно сделать первые шаги. Но все эти проблемы постепенно решаемы, это я могу сказать по своему собственному опыту работы с W-банком. Но при одном непременном условии: если такая госструктура как ФАПСИ будет заниматься только тем, что ей положено по ее статусу – ПРАВИТЕЛЬСТВЕННОЙ связью, и не будет совать свой ушлый нос туда, где нет военных и государственных секретов.
К счастью, W-банк трезво оценивал ФАПСИ. Разрешено все, что не запрещено законом, а если чиновники не могут грамотно составить закон, то это их проблемы. Первая версия автоматизированной системы электронного документооборота для W-банка была создана примерно через полгода. Конечно, первый подобный блин всегда получается немного неуклюжим, не совсем оптимальным, но он заработал! Это была еще DOS-версия, но даже в таком первобытном виде эта система устроила банк намного лучше, чем работа до одурения молодых девчонок. А в моей криптографической эпопее наступил Next step – разработка автоматизированных криптографических систем под конкретного заказчика. Я наконец-то получил долгожданную самостоятельность!
Более 800 000 книг и аудиокниг! 📚
Получи 2 месяца Литрес Подписки в подарок и наслаждайся неограниченным чтением
ПОЛУЧИТЬ ПОДАРОКДанный текст является ознакомительным фрагментом.
Читайте также
Глава 17 DNS
Глава 17 DNS DNS – это Доменная Система Имен (Domain Name System). DNS преобразует символические имена машин в IP-адреса и наоборот – из IP-адреса в символическое имя. Для чего это нужно? Во-первых, человеку легче запомнить осмысленное имя – типа vasya.ru чем 195.66.195.42, а для компьютера проще
Глава 20 FTP
Глава 20 FTP Эта глава посвящена протоколу FTP, настройке сервера FTP, проблемам конфигурации и безопасности сервера.Протокол FTPПротокол FTP (File Transfer Protocol, протокол передачи файлов) предназначен для передачи файлов в сети Интернет. Этот протокол был разработан на заре эры
ГЛАВА 14
ГЛАВА 14 Переменные среды и интерпретатора shellЧтобы продуктивно работать с интерпретатором shell, нужно уметь управлять переменными этого интерпретатора. Переменными интерпретатора shell являются наименования, которым присваиваются значения. В качестве значений может
ГЛАВА 15
ГЛАВА 15 Использование кавычекВ главе 14 обсуждались методы работы с переменными и операции подстановки. Чаще всего ошибки в использовании кавычек возникают при выполнении подстановок переменных в сценариях. Кавычки оказывают существенное влияние на формирование
ГЛАВА 16
ГЛАВА 16 Понятие о shell–сценарииВ shell–сценарий может включаться одна или несколько команд; здесь нет общепринятых правил. Зачем же создавать целый сценарий ради двух–трех команд? Все зависит от предпочтений пользователя.В этой главе рассматриваются следующие
ГЛАВА 17
ГЛАВА 17 Проверка условийПри создании сценария уточняется идентичность строк, права доступа к файлу или же выполняется проверка численных значений. На основе результатов проверки предпринимаются дальнейшие действия. Проверка обычно осуществляется с помощью команды test.
ГЛАВА 18
ГЛАВА 18 Управляющие конструкцииВсе функциональные сценарии должны предлагать возможности по выбору возможных вариантов. При определенных условиях сценарии должны выполнять обработку списков. Этим вопросам посвящена настоящая глава. Кроме того, в ней описывается
ГЛАВА 19
ГЛАВА 19 Функции интерпретатора shellДо сих пор весь программный код сценариев данной книги выполнялся последовательно от начала до конца программы. Подобный подход неплох, но при этом некоторые фрагменты кода, рассмотренного в наших примерах, дублируются в пределах
ГЛАВА 21
ГЛАВА 21 Создание экранного выводаС помощью shell–сценариев можно создавать профессионального вида экраны, позволяющие реализовать интерактивное взаимодействие пользователя с системой. Для этого достаточно располагать цветным монитором и использовать команду tput.В
ГЛАВА 22
ГЛАВА 22 Создание экранного вводаКогда речь идет об экранном вводе, или вводе данных, подразумевают ввод информации (в нашем случае с помощью клавиатуры), а затем — проверку достоверности введенных данных. Если данные удовлетворяют неким критериям, они
ГЛАВА 23
ГЛАВА 23 Отладка сценариевОдной из самых сложных задач при создании shell–сценариев является их отладка. Желательно, чтобы пользователь, выполняющий эту задачу, получил консультации на данном этапе. Чтобы избежать распространенных ошибок, достаточно следовать указанному
ГЛАВА 24
ГЛАВА 24 Встроенные команды интерпретатора shellВ предыдущих главах нам уже встречались конструкции, встроенные в интерпретатор shell Напомним, что речь идет о командах, которые не находятся в каталоге /bin или usr/bin, а встроены в интерпретатор Bourne shell. Скорость выполнения
ГЛАВА 25
ГЛАВА 25 Дальнейшее изучение конструкции "документ здесь"При рассмотрении стандартного потока ввода и вывода, а также циклов while уже обсуждалась конструкция "документ здесь". Описывались методика пересылки электронной почты и способы формирования экранов меню, но
ГЛАВА 26
ГЛАВА 26 Утилиты интерпретатора shellВ этой главе рассматриваются следующие темы: • создание датируемых имен файлов и временных файлов; • сигналы; • команда trap и способы перехвата сигналов; • команда eval; • команда
ГЛАВА 28
ГЛАВА 28 Сценарии уровня выполненияЕсли при загрузке системы вам нужно автоматически запустить приложение, службу или сценарий либо корректно завершить их работу при перезапуске системы, то необходимо создать сценарий уровня выполнения. Почти все варианты системы Linux, а
ГЛАВА 29
ГЛАВА 29 Сценарии cgiВ настоящее время, когда практически на каждом ПК установлен Web–сервер, глава, посвященная сценариям cgi, органически вписывается в книгу по shell–программированию.В главе будут рассмотрены следующие темы: • базовые сценарии cgi; • использование