![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Бюрократизмы и карго-культ в разработке софта
Продолжаем препарирование любимой компании?
Работала старая система выполнения нарядов. Где-то они выписываются, а на станциях выполняются. Автоматизировано это было (дай памяти, Невидимый Голубой Единорог) году в 98-99. С тех пор система, или даже точнее - её компоненты, только совершенствовались и улучшались. Помнится в первые годы вся эта кухня у меня работала на дельфях под OS/2. В качестве БД - interbase. Против интербейза ничего плохого не имею - хорошая, шустрая и лёгкая база. И даже с UDF замечательно позволяет затачивать функции и необходимости. Проблемы были, конечно. В частности если по сети что-то глюкануло, то клиент замерзал и соответственно стопорился весь процесс. Приходилось сменному инженеру перезагружать комп. Происходило это регулярно. Не каждый день. Могло, конечно, повториться и на следующий, но в среднем получалось раз в неделю.
Со временем база (оперативная) переползла на локальный сервер. Ну, конечно, главное что и сервер такой появился. И самое главное что робот стал работать не на рабочей станции, а прямо на сервере под линуксом. Ну и станция, естественно, под боком. К тому времени появились наработки на php. Система заматерела и расширилась. Абонентам стали добавлять не просто услуги, но началось автоматизированное отключение задолжников. А это уже совсем другая интенсивность нарядов.
Проблемы, конечно, были, но уже не требовали ручного вмешательства. Естественно, система продолжала отлаживаться и улучшаться. Наметил было смену концепции, языка и т.п. Вместо нескольких параллельных баз (на разные подсистемы) собирался объединить всё в одну единую. Они и логично — хорошо когда вся информация по абоненту в одном месте. Но как всегда в таком случае получается, глобальные изменения всё оттягивались и конца и края этому не было видно. Оно и правда: кому хочется что-то менять, если оно всё и так более-менее работает. Мелкие проблемки есть, но они уже все известны и понятно как с ними бороться. А в новой обязательно будут ещё неизведанные ошибки, и не факт, что в саму концепцию не заберётся фундаментальная ошибка. :)
Помог случай. Сдох на сервере винт, на котором крутилось всё это хозяйство. И конечно-же, оперативного бекапа не было. Поэтому пришлось оперативно писать новых роботов. Благо наработки уже были в одной из подсистем. Пока всё писалось неделю-две наряды выполнялись в полуавтоматическом режиме: сгенерировать скрипты, отправить на исполнение, сгенерировать отчёты по выполнению нарядов, отправить ответы. Поток нарядов на допуслуги жиденький, задолжников тогда отключали только своих собственных, а во второй круг отключения попадали только пара сторонников. Лафа. :)
Так родилась действующая система. Лет пять назад. Работает оперативно и надёжно. Даже автоматизированные механизмы восстановления событий при случайных сбоях предусмотрены. Но враги не спят. В существующей АСР напридумывали всякую хрень, из-за чего операторы могут неправильно оформлять наряды и никто их об этом не предупреждает. По команде до нас доходит нагоняй почему чего-то там не сделано. Приходится мне обращаться к айтишникам: "почему такой-то наряд до меня не дошёл?". Посидят, поразбираются: "неправильно оформлен наряд", "наряд оформили задним числом". Иногда начальство заставляет вносить изменения вручную. Но, ёлки-зелёные, консистентность-то падает! Центральная АСР потом не знает что у абонента уже нет какой-то услуги, если она отключена таким левым путём. И мой робот тоже об этом не знает.
Плохо? Естественно. Но я и не подозревал, что может быть гораздо хуже. Точнее, я не подозревал, насколько хуже может стать.
Высокое Начальство решило поставить новую систему (где-то там, где АСР). По неделям система не работает когда какие-то изменения вносятся. Абоненты выпадают из обслуживания. Теперь наряды автоматически не закрываются. Сменный должен в ПО обходить несколько десятков пунктов меню (группированные по абонентским выносам, но типам услуг и пр.) чтобы закрывать выполненные роботом наряды. А каждый неплохо бы проверить, потому что не понятно выполнен он или нет. А то мало ли чего там в системе написано.
Единственно что мне непонятно, это "как?" так можно писать софт. Даже не разбираясь в технологических процессах, чисто интуитивно должна возникнуть мысль что так делать нельзя потому что:
1. Нарядов можеть быть дохрена и человек такое количество обработать просто физически не сможет.
2. Ручное выполнение чревато ошибками. Ошибка в роботе может быть, но живёт ровно до устранения. Ошибка человека (вероятность на несколько порядков выше) может повторяться и проявляться где угодно, когда угодно и гарантированно "устранить" их источник невозможно в отличие от ПО.
3. Эффективность выполнения нарядов роботом на несколько порядков выше. О какой производительности труда можно в такой ситуации говорить? Какие инвестиции? Какой ВВП? С таким подходом будет только хуже.
Работала старая система выполнения нарядов. Где-то они выписываются, а на станциях выполняются. Автоматизировано это было (дай памяти, Невидимый Голубой Единорог) году в 98-99. С тех пор система, или даже точнее - её компоненты, только совершенствовались и улучшались. Помнится в первые годы вся эта кухня у меня работала на дельфях под OS/2. В качестве БД - interbase. Против интербейза ничего плохого не имею - хорошая, шустрая и лёгкая база. И даже с UDF замечательно позволяет затачивать функции и необходимости. Проблемы были, конечно. В частности если по сети что-то глюкануло, то клиент замерзал и соответственно стопорился весь процесс. Приходилось сменному инженеру перезагружать комп. Происходило это регулярно. Не каждый день. Могло, конечно, повториться и на следующий, но в среднем получалось раз в неделю.
Со временем база (оперативная) переползла на локальный сервер. Ну, конечно, главное что и сервер такой появился. И самое главное что робот стал работать не на рабочей станции, а прямо на сервере под линуксом. Ну и станция, естественно, под боком. К тому времени появились наработки на php. Система заматерела и расширилась. Абонентам стали добавлять не просто услуги, но началось автоматизированное отключение задолжников. А это уже совсем другая интенсивность нарядов.
Проблемы, конечно, были, но уже не требовали ручного вмешательства. Естественно, система продолжала отлаживаться и улучшаться. Наметил было смену концепции, языка и т.п. Вместо нескольких параллельных баз (на разные подсистемы) собирался объединить всё в одну единую. Они и логично — хорошо когда вся информация по абоненту в одном месте. Но как всегда в таком случае получается, глобальные изменения всё оттягивались и конца и края этому не было видно. Оно и правда: кому хочется что-то менять, если оно всё и так более-менее работает. Мелкие проблемки есть, но они уже все известны и понятно как с ними бороться. А в новой обязательно будут ещё неизведанные ошибки, и не факт, что в саму концепцию не заберётся фундаментальная ошибка. :)
Помог случай. Сдох на сервере винт, на котором крутилось всё это хозяйство. И конечно-же, оперативного бекапа не было. Поэтому пришлось оперативно писать новых роботов. Благо наработки уже были в одной из подсистем. Пока всё писалось неделю-две наряды выполнялись в полуавтоматическом режиме: сгенерировать скрипты, отправить на исполнение, сгенерировать отчёты по выполнению нарядов, отправить ответы. Поток нарядов на допуслуги жиденький, задолжников тогда отключали только своих собственных, а во второй круг отключения попадали только пара сторонников. Лафа. :)
Так родилась действующая система. Лет пять назад. Работает оперативно и надёжно. Даже автоматизированные механизмы восстановления событий при случайных сбоях предусмотрены. Но враги не спят. В существующей АСР напридумывали всякую хрень, из-за чего операторы могут неправильно оформлять наряды и никто их об этом не предупреждает. По команде до нас доходит нагоняй почему чего-то там не сделано. Приходится мне обращаться к айтишникам: "почему такой-то наряд до меня не дошёл?". Посидят, поразбираются: "неправильно оформлен наряд", "наряд оформили задним числом". Иногда начальство заставляет вносить изменения вручную. Но, ёлки-зелёные, консистентность-то падает! Центральная АСР потом не знает что у абонента уже нет какой-то услуги, если она отключена таким левым путём. И мой робот тоже об этом не знает.
Плохо? Естественно. Но я и не подозревал, что может быть гораздо хуже. Точнее, я не подозревал, насколько хуже может стать.
Высокое Начальство решило поставить новую систему (где-то там, где АСР). По неделям система не работает когда какие-то изменения вносятся. Абоненты выпадают из обслуживания. Теперь наряды автоматически не закрываются. Сменный должен в ПО обходить несколько десятков пунктов меню (группированные по абонентским выносам, но типам услуг и пр.) чтобы закрывать выполненные роботом наряды. А каждый неплохо бы проверить, потому что не понятно выполнен он или нет. А то мало ли чего там в системе написано.
Единственно что мне непонятно, это "как?" так можно писать софт. Даже не разбираясь в технологических процессах, чисто интуитивно должна возникнуть мысль что так делать нельзя потому что:
1. Нарядов можеть быть дохрена и человек такое количество обработать просто физически не сможет.
2. Ручное выполнение чревато ошибками. Ошибка в роботе может быть, но живёт ровно до устранения. Ошибка человека (вероятность на несколько порядков выше) может повторяться и проявляться где угодно, когда угодно и гарантированно "устранить" их источник невозможно в отличие от ПО.
3. Эффективность выполнения нарядов роботом на несколько порядков выше. О какой производительности труда можно в такой ситуации говорить? Какие инвестиции? Какой ВВП? С таким подходом будет только хуже.