Начал смотреть видео — думал надо же, неужели теперь сап выглядит нормально… Так в начале видео красиво было (не по сравнению с изысками дизайна в вебе, а по сравнению с R/3 4.0B, с которым я работал)…
Дальше стало ясно — просто красивый скин и чуть-чуть окно изменили… Внутри — всё то же, иконки те же, модель интерфейса та же… Да и сложно сделать вменяемый интерфейс, оперируя SQL-подобным языком (ABAP/4 там, для тех, кто не знает)…
Тут на следующих выходных не только день железнодорожника, но и всероссийская админопопойка (http://sletadminov.ru), чувствую, надо отпуск брать, одними выходными всё не отметить :)
Нужен блог… Но нельзя — отключили на хабре возможность создавать новые коллективные блоги :(
А так да, ШЧ — дистанция связи, шунтовая часть. Правда, народ, когда хочет над ними поприкалываться расшифровывает их как «шнуровая часть», на что они слегка обижаются :)
Кстати, сейчас их тоже выводят из состава дорог в отдельные департаменты. Так, сейчас большая часть ШЧ'шников относятся к РЦС (региональный центр связи).
Обещанные фотки оборудования в машзалах МИВЦ МЖД ОАО РЖД (московского информационно-вычислительного центра московской железной дороги — филиала ОАО Российские Железные Дороги — меня всегда убивало в документах полное название организации и подразделения писать): picasaweb.google.ru/LinFor/quvii?feat=directlink
Сейчас особо нету времени оформлять как пост, да и я уже не так хорошо помню, где там что нафоткано — но минимальные комментарии есть :)
Физический. Тормоза в поездах пневматические — вдоль всего состава идёт тормозная магистраль, в которой воздух под давлением. Именно от этих магистралей и видны рукава (шланги) между вагонами.
В случае пропадания давления в тормозной магистрали тормозные колодки падают на колёса — выполняется торможение. «Стоп-кран» — это именно кран, напрямую соединённый с тормозной магистралью и по-умолчанию закрытый. Если его открыть — воздух начнёт выходить и будет выполнено торможение.
Вот уж никогда бы не подумал, что в Белоруссии всё это делают руками :) Поэтому, расскажу, как сиё происходит у нас.
На самом деле, умные дядьки из отраслевых проектных институтов (ВНИИАС, ВНИИЖТ, ВНИИУП и прочие — на самом деле у дороги очень много отраслевых научных заведений) давно смекнули, что каждый раз составлять новый график — есть рутина. Поэтому придумали способ управления перевозочным процессом с использованием т.н. «ниток графика» (а заодно и обеспечить себя хлебом насущным).
Фактически, нитка графика — это как раз то, что расписывается в посте. Т.е. фактически, некая возможность пропуска поезда из пункта А в пункт Б.
Так вот, умные дядьки придумали, что можно один раз рассчитать все такие возможные нитки — с учётом кучи разных параметров, таких как загруженность линий, минимальный интервал пропуска поездов по путям и т.д.
На выходе получается громадный объём таких ниток. Нитки тоже бывают разными — например гибкие и твёрдые. Гибкие — это низкоприоритетные, поезд на которых можно приостановить в случае, если путь нужен под поезд с большим приоритетом. Твёрдые — это по сути и есть высокоприоритетные нитки, с гарантией времени прохождения.
На самом деле, процесс формирования этих данных очень сложен — он учитывает и вероятные задержки в пути, и возможные флуктуации нагрузки сети (вызванные, например, какими-либо аварийными или плановыми работами на путях).
Т.е. несмотря на фиксированное время отправления, у всех ниток время прибытия плавающее — в некоторых пределах. И следующие нитки (между следующими двумя станциями) строятся уже с учётом того, что поезд может прийти раньше, а может и задержаться — обязательно существует продолжающая нитка, время отправления которой максимально приближено к «потолочному» времени прибытия поезда по нитке — чтобы он не простаивал на станции, а без остановок проследовал дальше. В работе поездные диспетчера видят эти допуски и координируют машинистов в плане «быстрее/медленнее езжай» :)
Из за огромной вычислительной сложности этой задачи — стоит формирование такого «метаграфика» немало. И РЖД закупает эту информацию у соответствующих проектных учреждений. Но, как правило эти данные формируются один раз и надолго (эдакий «кэш»).
При формировании поезда остаётся лишь присвоить ему класс, из которого будет видно, на какие нитки его можно ставить и примерное время прибытия. Для высокоприоритетных поездов, естественно, выбираются твёрдые нитки графика, и время прибытия на конечный пункт становится гарантированным.
Сейчас, когда ОАО РЖД решило «раздробиться» (сейчас идёт активное дробление внутренних подразделений, некоторые из них совсем выводятся из состава ОАО РЖД, ключевые не выводятся, но переводятся на самофинансирование — т.е. если раньше все службы дотировались из ОАО и не получали своих доходов, то теперь они все предоставляют друг другу услуги, берут друг с друга деньги и т.д. — в общем, пытаются окупаться. Особо неприбыльные задачи вообще хотят передать в аутсорс) ключевой идеей для дорог стала продажа ниток графика. Твёрдые, понятное дело, стоят дороже :)
Грузовые локомотивы во-первых как правило медленнее (передаточные отношения завалены вниз), во-вторых у них напрочь отсутствует плавность хода, присутствуют сильные продольные вибрации.
Пассажирские локомотивы напротив, плавнее и шустрее, за счёт того, что тягают лёгкие составы.
На СКЖД наш поезд таскали двумя секциями ВЛ10. А его пассажирским ну никак не назвать.
Кстати, там почти все пассажирские поезда таскаются сцепками ВЛ10 :)
Насколько я знаю, сайт работает на базе IBM WebSphere Portal, в качестве железа там IBM P550. Другое дело, что порой при запросе (тех же свободных мест) он пересылает запросы другим системам (той же АСУ Экспресс 3, например), у которых совсем не гарантированный отклик.
Воруют, и воруют по-разному. ИТшники как правило не воруют вообще, а живут за счёт откатов с закупок и подрядов.
А вот на линейных предприятиях жёстко. Медь тащат все — СЦБшники, ЭЧшники (короче все, у кого на работе так или иначе встречаются обмотки, трансформаторы и т.д.) Драгметаллы иногда с контакторов и других устройств.
В ТЧ (тяговая часть) вообще цирк. Там сливают ДТ, причём порой в масштабах, немыслимых для заправок.
Например, бак популярного маневрового ЧМЭ3 имеет запас топлива 6 тонн. Да, используются датчики, счётчики, пломбы, но все эти системы защиты легко обходятся «находчивыми» машинистами: механические — всевозможными магнитами и плёнками, электронные — сверхнадёжным «кувалдометром». Даже несмотря на санкции и штрафы, прибыль от реализации получаемого топлива с лихвой перекрывает зарплату машиниста на пару месяцев.
Собственно, неофициальным распоряжением начальника дороги все начальники ТЧ обязаны вести реестр сотрудников, имеющих в своей собственности (или родственников) автомобили с дизельными тяговыми агрегатами. Но, тоже не спасает, ибо топливом активно торгуют.
В самих же ТЧ бывает, тоже сливают. Относительно свежа байка про случай, когда слесаря, якобы без ведома начальника ТЧ, умудрились к заполненному топливом (!!!) резервуару (из которого наполняются баки локомотивов) приварить трубу и через холмик и лесок вывести её в соседнюю деревню. А там была избушка, в которой был краник, про который знала вся деревня и «приближённые», чем успешно пользовались несколько лет.
Разрабатывают АСУ Экспресс вроде бы совместно ВНИИЖТ и ВНИИУП. И что самое странное, у нас именно в «экспрессе» (в смысле в отделе, который его обслуживал) была меньше всего текучка кадров и самые грамотные люди. Я, помню, очень жалел, что туда не попал — а ведь у меня был выбор, мог бы работать практически в любом отделе ИВЦ. Но, к сожалению, я тогда слишком мало знал о системах дороги и что там как устроено :)
Вот с чем-чем, а с обучением в РЖД проблем нет вообще.
Существует план обучения, на откаты с этого плана живёт немало народа, поэтому обучения много и оно весьма разнообразно. Срывать план обучения (т.е. отказываться учиться либо же не являться на обучение) крайне не рекомендуется — можно получить по шапке от довольно большой цепочки, которая начинается в департаменте (ОАО РЖД — головной холдинг) и заканчивается непосредственным начальником.
Курсы разнообразны, их довольно много, лично я неоднократно «учился» в РедЦентре (большей частью потому, что там были халявные обеды в каком-никаком, а ресторане, и кроме того, до определённого момента на прогулы там смотрели сквозь пальцы). Собственно, за счёт того, что для начальства единственным смыслом отправки сотрудников на курсы является обеспечение выполнения плана обучения (а вовсе не повышение квалификации подчинённых) — можно было попасть на курсы, к которым твоя должность вообще никаким боком не относится (главное найти нужный список и «вписаться» туда), а иной раз сходить несколько раз на одно и то же — я, например, раза три был на курсе по PL/SQL в Oracle 10g. Да, я либо вообще не появлялся там, либо тупо спал и лазил в инете.
Ни на какие сертификационные экзамены и т.д. с дороги не посылают — большей частью потому, что они дешёвые, а основной целью обучения на дороге является — см. начало каммента.
Кроме редцентра есть и другие замечательные места, в том числе и в других городах — в частности несколько раз предлагали съездить в питер в диджиталдизайн, но с командировками было не очень приятно — во-первых, несмотря на бесплатные билеты, суточных платили всего 100 руб/день (я что-то сомневаюсь, что в питере можно было вменяемо на эту сумму жить), во-вторых ехать надо было за свой счёт, а потом, через пару-тройку месяцев, эта сумма компенсировалась. Меня сиё положение дел не шибко устраивало и я всегда умудрялся отмазаться от командировок.
Тем не менее, ребят с других дорог на обучении бывает много. С самых разных концов страны — даже из Хабаровска, Иркутска приезжали в москву в редцентр. На самом деле, только в микроинформе я встретил на курсах ребят не с дороги (один был с мегафона, другой вроде с билайна), во всех остальных случаях дорога просто бронировала все помещения на неделю-две и туда с разных предприятий стекались железнодорожники на обучение. Т.е. всегда все свои.
На самом деле нет. По крайней мере год назад было ещё не на сапе.
Зарплата на МЖД считалась некоей «АРМ Зарплата», написанной в недрах НИЛ АБУ МИИТа (научно-исследовательская лаборатория автоматизации бухгалтерского учёта московского института инженеров транспорта (МИИТ нынче правильно называется МГУПС, но на это никто не обращает внимания) ). Писана на дельфи, база — MS SQL. Одно время эта система находилась в моём ведении, поэтому про неё-то я хорошо знаю :)
Под эту систему у нас стояло 8 машинок Compaq ML350 (G3, G5) + сторейджи + у каждой машинки был свой стриммер. Короче — шкафчик целиком :)
На удивление, машинки были даже не в кластере, каждая сама по-себе, а балансировка нагрузки между ними реализовывалась простым дедовским способом — разные предприятия на разных машинках.
Примерно летом 2008-го года МИИТ почуял жареное (уже давно ходили разговоры о том, что неплохо бы расчёт зарплаты перенести в SAP) и понял, что надо рубить как можно больше денег, пока ещё можно. И в одном из последних (на тот момент) обновлений была введена т.н. «авторизация» (по сути МИИТ придумал и поставил у себя авторизационный сервер и прога стала проверять присутствие логинящегося пользователя на нём — чем больше пользователей зарегистрировано в системе — тем больше дороги заплатят денежек — эдакий вот «SaaS»). С этого момента началась чехарда. А именно, нужно было в сжатые сроки завести огромное количество пользователей (уже не помню, кажется около 3000, точно помню, что было около 300 предприятий). Срок же был вполне обозримый — что-то около месяца, кажется.
Всё бы ничего (подумаешь, 3000 пользователей), но никакого API либо какого-либо другого механизма пакетной загрузки МИИТ не предоставил. Заведение пользователей осуществлялось через GUI их системы, причём в трёх разных местах — один раз на нашем сервере, второй раз в MS SQL, третий — на их авторизационном сервере через предоставленную прогу. В принципе, в MS SQL по документации ничего делать было не нужно, но на практике при заведении из их проги часто некорректно выставлялись роли учётке в SQL Server'е.
Надо упомянуть, что жизнь пользователей на железке — тоже далеко не сахар. Особенно вновь пришедшим. Пользователю, чтобы получить доступ к какой-либо ИС (информационной системе) нужно было оформить заявку, подписать её в нескольких (штук 5) инстанциях и уже подписанную принести нам — точнее, администраторам той ИС, к которой нужен доступ. Так вот, если первая подпись была тривиальной — подпись начальника, то вот все остальные «инстанции» находились в Москве. Это:
2. администратор системы информационной безопасности
3. начальник отдела информационной безопасности
4. зам начальника дороги по информационной безопасности
5. собственно, администратор той самой ИС (который и будет заводить учётку)
Интересно, что товарисчи «3» и «4» подписывают только при наличии подписей «1», «2» и «5». А тов. Минаков «4» — довольно большой начальник (зам начальника МЖД) и застать его на месте (не то, что уговорить подписать) — довольно проблемно.
Поэтому на практике оформление заявок на доступ к различным ИС занимало довольно продолжительное время, заявки привозились в москву с попутными командированными (которых просто просили «передать бумажки в ИВЦ»), те с неохотой (после того, как им разъясняли, что просто бумажки с одной подписью нам совершенно не нужны) начинали бродить по коридорам и переходам управления МЖД, разыскивая нужные кабинеты. Порой этим приходилось заниматься и нам (мы же не звери, если видели, что принесла заявки какая-нить старушка-пенсионерка или типа того — с глубоким вздохом забирали их и сами носили на подпись). Одним днём оформление заявок заканчивалось редко, главным образом из-за отсутствия товарисча «4» или неправильно оформленных заявок (там есть несколько форм, на некоторые ИС нужны отдельные формы). Вся эта чехарда повторяется каждый год, ибо заявки оформляются сроком не более чем на год.
Так вот, вернёмся к нашим баранам (эээ, в смысле к зарплатам :) ). Почти сразу стало ясно, что в отведённый срок мы столько пользователей не заведём. И тут проблема была даже не в способе заведения (через GUI), а скорее в том, что не было оформленных заявок (все предприятия имели по одной учётке и все сотрудники работали из-под неё, оформлена она была чёрте-когда на чёрте-кого и никто не парился даже с продлением). Подняв на уши почти весь базис мы за три дня не сделали практически ничего. Надо было что-то решать.
Первым делом была нафиг отломана эта авторизация. Наши локальные проблемы это решило, но отдавать на дорогу отломанный екзешник было нельзя — грозило большим скандалом в случае чего. Поэтому сиё решение оставили на потом — на случай, если совсем будет плохо.
Со вторым шагом заведения я расквитался практически сразу же. Были написаны соответствующие SQL-скрипты, которые парсили большой csv на входе и прогоняли нужные команды на сервере.
Затем, ещё через денёк сдался и первый шаг — я начал запихивать нужные строки в нужные таблицы на наших серверах, нашёл подошедшие алгоритмы хеширования строк и т.д. — короче, из того же csv я заводил пользователя, неотличимого от заведённого через GUI.
С третьим шагом было сложнее — не было доступа к таблицам в МИИТе, хоть мне и удалось довольно быстро выдрать учётку, под которой тулза коннектилась к MSSQL — но вся работа там шла через хранимки, им передавались какие-то непонятные параметры, а все возвращаемые хранимками данные были неким образом пошифрованы.
На помощь пришёл старый добрый DeDe. Поковыряв в нём МИИТовские тулзы я узнал много нового о МИИТе и людях, делавших эту систему :) Особенно меня порадовал вшитый в код ключ от алгоритма шифрования («buratino» — естественно, настоящий я не пишу, но принцип и криптостойкость такая же :) ), над его криптостойкостью мы ржали всем базисом. Жаль, но с реверсингом я проковырялся довольно долго, уже начали массово приходить заявки, и автоматизировать третий шаг мне так и не удалось.
Но третий шаг был самым простым и быстрым, не требовал сверки прав — в общем, на него мы посадили присутствующих «без дела» девочек-припевочек, которым заняться было нечем, кроме как красить ногти и мечтать о принцах. Поворчали, но против «указа царя» не попрёшь.
В общем, мне удалось сократить трудоёмкость раза в четыре. Имеющиеся к тому моменту заявки обработали в тот же день, самым сложным стал перенос инфы с бумажной заявки в csv. Кроме того, процесс оформления бумажных заявок явно не хотел ускоряться.
На очередном совещании было принято решение принимать «электронные» заявки (а по сути — просто присланный на почту список сотрудников предприятия) под честное слово начальника предприятия в дальнейшем оформить все бумажные. С этого момента дело «пошло».
В общем, в срок мы уложились. Единственные, за что я весьма горд. А в результате МИИТ, поворчав и потыкав пальцем в нашу сторону, отодвинул сроки ещё на месяц или два — т.к. фактически по сети дорог план перехода на авторизацию МИИТа был сорван.
PS: Прошу прощения за длиннющий каммент, чего-то прям вспомнилось и понесло. Собственно, возможно зарплата уже и считается в SAP'е, но зарплата машинистам очень врядли. Там довольно запутанный алгоритм расчёта, который использует данные по путевым ведомостям, которые просто не передаются в SAP. Собственно, на каком-то этапе и хотели перенести в SAP весь расчёт, кроме машинистов — скорее всего так и сделали.
Там не электромагниты — там электродвигатель и червячная передача :)
Кстати, бывалые СЦБисты носят с собой ложки. Обычные, столовые, ложки. :) Так вот, когда какой сбой на приводе стрелки (бывает такое иногда) они, грамотно просунув внутрь ложку, умудряются замыкать ею нужные контакты, и соответственно, принудительно переводить стрелку в любое положение :)
О, надо тоже почитать :) А то я читал только цитаты из неё во всяких учебниках :) В частности сигналы светофора и про фонари в голове и хвосте поезда :)
Дальше стало ясно — просто красивый скин и чуть-чуть окно изменили… Внутри — всё то же, иконки те же, модель интерфейса та же… Да и сложно сделать вменяемый интерфейс, оперируя SQL-подобным языком (ABAP/4 там, для тех, кто не знает)…
Кстати, наши СЦБисты всегда расшифровывали себя как «Собака Цепная Бешеная» :)
А так да, ШЧ — дистанция связи, шунтовая часть. Правда, народ, когда хочет над ними поприкалываться расшифровывает их как «шнуровая часть», на что они слегка обижаются :)
Кстати, сейчас их тоже выводят из состава дорог в отдельные департаменты. Так, сейчас большая часть ШЧ'шников относятся к РЦС (региональный центр связи).
Сейчас особо нету времени оформлять как пост, да и я уже не так хорошо помню, где там что нафоткано — но минимальные комментарии есть :)
В случае пропадания давления в тормозной магистрали тормозные колодки падают на колёса — выполняется торможение. «Стоп-кран» — это именно кран, напрямую соединённый с тормозной магистралью и по-умолчанию закрытый. Если его открыть — воздух начнёт выходить и будет выполнено торможение.
Это вкратце и по-простому, подробнее тут
На самом деле, умные дядьки из отраслевых проектных институтов (ВНИИАС, ВНИИЖТ, ВНИИУП и прочие — на самом деле у дороги очень много отраслевых научных заведений) давно смекнули, что каждый раз составлять новый график — есть рутина. Поэтому придумали способ управления перевозочным процессом с использованием т.н. «ниток графика» (а заодно и обеспечить себя хлебом насущным).
Фактически, нитка графика — это как раз то, что расписывается в посте. Т.е. фактически, некая возможность пропуска поезда из пункта А в пункт Б.
Так вот, умные дядьки придумали, что можно один раз рассчитать все такие возможные нитки — с учётом кучи разных параметров, таких как загруженность линий, минимальный интервал пропуска поездов по путям и т.д.
На выходе получается громадный объём таких ниток. Нитки тоже бывают разными — например гибкие и твёрдые. Гибкие — это низкоприоритетные, поезд на которых можно приостановить в случае, если путь нужен под поезд с большим приоритетом. Твёрдые — это по сути и есть высокоприоритетные нитки, с гарантией времени прохождения.
На самом деле, процесс формирования этих данных очень сложен — он учитывает и вероятные задержки в пути, и возможные флуктуации нагрузки сети (вызванные, например, какими-либо аварийными или плановыми работами на путях).
Т.е. несмотря на фиксированное время отправления, у всех ниток время прибытия плавающее — в некоторых пределах. И следующие нитки (между следующими двумя станциями) строятся уже с учётом того, что поезд может прийти раньше, а может и задержаться — обязательно существует продолжающая нитка, время отправления которой максимально приближено к «потолочному» времени прибытия поезда по нитке — чтобы он не простаивал на станции, а без остановок проследовал дальше. В работе поездные диспетчера видят эти допуски и координируют машинистов в плане «быстрее/медленнее езжай» :)
Из за огромной вычислительной сложности этой задачи — стоит формирование такого «метаграфика» немало. И РЖД закупает эту информацию у соответствующих проектных учреждений. Но, как правило эти данные формируются один раз и надолго (эдакий «кэш»).
При формировании поезда остаётся лишь присвоить ему класс, из которого будет видно, на какие нитки его можно ставить и примерное время прибытия. Для высокоприоритетных поездов, естественно, выбираются твёрдые нитки графика, и время прибытия на конечный пункт становится гарантированным.
Сейчас, когда ОАО РЖД решило «раздробиться» (сейчас идёт активное дробление внутренних подразделений, некоторые из них совсем выводятся из состава ОАО РЖД, ключевые не выводятся, но переводятся на самофинансирование — т.е. если раньше все службы дотировались из ОАО и не получали своих доходов, то теперь они все предоставляют друг другу услуги, берут друг с друга деньги и т.д. — в общем, пытаются окупаться. Особо неприбыльные задачи вообще хотят передать в аутсорс) ключевой идеей для дорог стала продажа ниток графика. Твёрдые, понятное дело, стоят дороже :)
Пассажирские локомотивы напротив, плавнее и шустрее, за счёт того, что тягают лёгкие составы.
Кстати, там почти все пассажирские поезда таскаются сцепками ВЛ10 :)
А вот на линейных предприятиях жёстко. Медь тащат все — СЦБшники, ЭЧшники (короче все, у кого на работе так или иначе встречаются обмотки, трансформаторы и т.д.) Драгметаллы иногда с контакторов и других устройств.
В ТЧ (тяговая часть) вообще цирк. Там сливают ДТ, причём порой в масштабах, немыслимых для заправок.
Например, бак популярного маневрового ЧМЭ3 имеет запас топлива 6 тонн. Да, используются датчики, счётчики, пломбы, но все эти системы защиты легко обходятся «находчивыми» машинистами: механические — всевозможными магнитами и плёнками, электронные — сверхнадёжным «кувалдометром». Даже несмотря на санкции и штрафы, прибыль от реализации получаемого топлива с лихвой перекрывает зарплату машиниста на пару месяцев.
Собственно, неофициальным распоряжением начальника дороги все начальники ТЧ обязаны вести реестр сотрудников, имеющих в своей собственности (или родственников) автомобили с дизельными тяговыми агрегатами. Но, тоже не спасает, ибо топливом активно торгуют.
В самих же ТЧ бывает, тоже сливают. Относительно свежа байка про случай, когда слесаря, якобы без ведома начальника ТЧ, умудрились к заполненному топливом (!!!) резервуару (из которого наполняются баки локомотивов) приварить трубу и через холмик и лесок вывести её в соседнюю деревню. А там была избушка, в которой был краник, про который знала вся деревня и «приближённые», чем успешно пользовались несколько лет.
Существует план обучения, на откаты с этого плана живёт немало народа, поэтому обучения много и оно весьма разнообразно. Срывать план обучения (т.е. отказываться учиться либо же не являться на обучение) крайне не рекомендуется — можно получить по шапке от довольно большой цепочки, которая начинается в департаменте (ОАО РЖД — головной холдинг) и заканчивается непосредственным начальником.
Курсы разнообразны, их довольно много, лично я неоднократно «учился» в РедЦентре (большей частью потому, что там были халявные обеды в каком-никаком, а ресторане, и кроме того, до определённого момента на прогулы там смотрели сквозь пальцы). Собственно, за счёт того, что для начальства единственным смыслом отправки сотрудников на курсы является обеспечение выполнения плана обучения (а вовсе не повышение квалификации подчинённых) — можно было попасть на курсы, к которым твоя должность вообще никаким боком не относится (главное найти нужный список и «вписаться» туда), а иной раз сходить несколько раз на одно и то же — я, например, раза три был на курсе по PL/SQL в Oracle 10g. Да, я либо вообще не появлялся там, либо тупо спал и лазил в инете.
Ни на какие сертификационные экзамены и т.д. с дороги не посылают — большей частью потому, что они дешёвые, а основной целью обучения на дороге является — см. начало каммента.
Кроме редцентра есть и другие замечательные места, в том числе и в других городах — в частности несколько раз предлагали съездить в питер в диджиталдизайн, но с командировками было не очень приятно — во-первых, несмотря на бесплатные билеты, суточных платили всего 100 руб/день (я что-то сомневаюсь, что в питере можно было вменяемо на эту сумму жить), во-вторых ехать надо было за свой счёт, а потом, через пару-тройку месяцев, эта сумма компенсировалась. Меня сиё положение дел не шибко устраивало и я всегда умудрялся отмазаться от командировок.
Тем не менее, ребят с других дорог на обучении бывает много. С самых разных концов страны — даже из Хабаровска, Иркутска приезжали в москву в редцентр. На самом деле, только в микроинформе я встретил на курсах ребят не с дороги (один был с мегафона, другой вроде с билайна), во всех остальных случаях дорога просто бронировала все помещения на неделю-две и туда с разных предприятий стекались железнодорожники на обучение. Т.е. всегда все свои.
Зарплата на МЖД считалась некоей «АРМ Зарплата», написанной в недрах НИЛ АБУ МИИТа (научно-исследовательская лаборатория автоматизации бухгалтерского учёта московского института инженеров транспорта (МИИТ нынче правильно называется МГУПС, но на это никто не обращает внимания) ). Писана на дельфи, база — MS SQL. Одно время эта система находилась в моём ведении, поэтому про неё-то я хорошо знаю :)
Под эту систему у нас стояло 8 машинок Compaq ML350 (G3, G5) + сторейджи + у каждой машинки был свой стриммер. Короче — шкафчик целиком :)
На удивление, машинки были даже не в кластере, каждая сама по-себе, а балансировка нагрузки между ними реализовывалась простым дедовским способом — разные предприятия на разных машинках.
Примерно летом 2008-го года МИИТ почуял жареное (уже давно ходили разговоры о том, что неплохо бы расчёт зарплаты перенести в SAP) и понял, что надо рубить как можно больше денег, пока ещё можно. И в одном из последних (на тот момент) обновлений была введена т.н. «авторизация» (по сути МИИТ придумал и поставил у себя авторизационный сервер и прога стала проверять присутствие логинящегося пользователя на нём — чем больше пользователей зарегистрировано в системе — тем больше дороги заплатят денежек — эдакий вот «SaaS»). С этого момента началась чехарда. А именно, нужно было в сжатые сроки завести огромное количество пользователей (уже не помню, кажется около 3000, точно помню, что было около 300 предприятий). Срок же был вполне обозримый — что-то около месяца, кажется.
Всё бы ничего (подумаешь, 3000 пользователей), но никакого API либо какого-либо другого механизма пакетной загрузки МИИТ не предоставил. Заведение пользователей осуществлялось через GUI их системы, причём в трёх разных местах — один раз на нашем сервере, второй раз в MS SQL, третий — на их авторизационном сервере через предоставленную прогу. В принципе, в MS SQL по документации ничего делать было не нужно, но на практике при заведении из их проги часто некорректно выставлялись роли учётке в SQL Server'е.
Надо упомянуть, что жизнь пользователей на железке — тоже далеко не сахар. Особенно вновь пришедшим. Пользователю, чтобы получить доступ к какой-либо ИС (информационной системе) нужно было оформить заявку, подписать её в нескольких (штук 5) инстанциях и уже подписанную принести нам — точнее, администраторам той ИС, к которой нужен доступ. Так вот, если первая подпись была тривиальной — подпись начальника, то вот все остальные «инстанции» находились в Москве. Это:
2. администратор системы информационной безопасности
3. начальник отдела информационной безопасности
4. зам начальника дороги по информационной безопасности
5. собственно, администратор той самой ИС (который и будет заводить учётку)
Интересно, что товарисчи «3» и «4» подписывают только при наличии подписей «1», «2» и «5». А тов. Минаков «4» — довольно большой начальник (зам начальника МЖД) и застать его на месте (не то, что уговорить подписать) — довольно проблемно.
Поэтому на практике оформление заявок на доступ к различным ИС занимало довольно продолжительное время, заявки привозились в москву с попутными командированными (которых просто просили «передать бумажки в ИВЦ»), те с неохотой (после того, как им разъясняли, что просто бумажки с одной подписью нам совершенно не нужны) начинали бродить по коридорам и переходам управления МЖД, разыскивая нужные кабинеты. Порой этим приходилось заниматься и нам (мы же не звери, если видели, что принесла заявки какая-нить старушка-пенсионерка или типа того — с глубоким вздохом забирали их и сами носили на подпись). Одним днём оформление заявок заканчивалось редко, главным образом из-за отсутствия товарисча «4» или неправильно оформленных заявок (там есть несколько форм, на некоторые ИС нужны отдельные формы). Вся эта чехарда повторяется каждый год, ибо заявки оформляются сроком не более чем на год.
Так вот, вернёмся к нашим баранам (эээ, в смысле к зарплатам :) ). Почти сразу стало ясно, что в отведённый срок мы столько пользователей не заведём. И тут проблема была даже не в способе заведения (через GUI), а скорее в том, что не было оформленных заявок (все предприятия имели по одной учётке и все сотрудники работали из-под неё, оформлена она была чёрте-когда на чёрте-кого и никто не парился даже с продлением). Подняв на уши почти весь базис мы за три дня не сделали практически ничего. Надо было что-то решать.
Первым делом была нафиг отломана эта авторизация. Наши локальные проблемы это решило, но отдавать на дорогу отломанный екзешник было нельзя — грозило большим скандалом в случае чего. Поэтому сиё решение оставили на потом — на случай, если совсем будет плохо.
Со вторым шагом заведения я расквитался практически сразу же. Были написаны соответствующие SQL-скрипты, которые парсили большой csv на входе и прогоняли нужные команды на сервере.
Затем, ещё через денёк сдался и первый шаг — я начал запихивать нужные строки в нужные таблицы на наших серверах, нашёл подошедшие алгоритмы хеширования строк и т.д. — короче, из того же csv я заводил пользователя, неотличимого от заведённого через GUI.
С третьим шагом было сложнее — не было доступа к таблицам в МИИТе, хоть мне и удалось довольно быстро выдрать учётку, под которой тулза коннектилась к MSSQL — но вся работа там шла через хранимки, им передавались какие-то непонятные параметры, а все возвращаемые хранимками данные были неким образом пошифрованы.
На помощь пришёл старый добрый DeDe. Поковыряв в нём МИИТовские тулзы я узнал много нового о МИИТе и людях, делавших эту систему :) Особенно меня порадовал вшитый в код ключ от алгоритма шифрования («buratino» — естественно, настоящий я не пишу, но принцип и криптостойкость такая же :) ), над его криптостойкостью мы ржали всем базисом. Жаль, но с реверсингом я проковырялся довольно долго, уже начали массово приходить заявки, и автоматизировать третий шаг мне так и не удалось.
Но третий шаг был самым простым и быстрым, не требовал сверки прав — в общем, на него мы посадили присутствующих «без дела» девочек-припевочек, которым заняться было нечем, кроме как красить ногти и мечтать о принцах. Поворчали, но против «указа царя» не попрёшь.
В общем, мне удалось сократить трудоёмкость раза в четыре. Имеющиеся к тому моменту заявки обработали в тот же день, самым сложным стал перенос инфы с бумажной заявки в csv. Кроме того, процесс оформления бумажных заявок явно не хотел ускоряться.
На очередном совещании было принято решение принимать «электронные» заявки (а по сути — просто присланный на почту список сотрудников предприятия) под честное слово начальника предприятия в дальнейшем оформить все бумажные. С этого момента дело «пошло».
В общем, в срок мы уложились. Единственные, за что я весьма горд. А в результате МИИТ, поворчав и потыкав пальцем в нашу сторону, отодвинул сроки ещё на месяц или два — т.к. фактически по сети дорог план перехода на авторизацию МИИТа был сорван.
PS: Прошу прощения за длиннющий каммент, чего-то прям вспомнилось и понесло. Собственно, возможно зарплата уже и считается в SAP'е, но зарплата машинистам очень врядли. Там довольно запутанный алгоритм расчёта, который использует данные по путевым ведомостям, которые просто не передаются в SAP. Собственно, на каком-то этапе и хотели перенести в SAP весь расчёт, кроме машинистов — скорее всего так и сделали.
Кстати, бывалые СЦБисты носят с собой ложки. Обычные, столовые, ложки. :) Так вот, когда какой сбой на приводе стрелки (бывает такое иногда) они, грамотно просунув внутрь ложку, умудряются замыкать ею нужные контакты, и соответственно, принудительно переводить стрелку в любое положение :)