Не могу согласиться. Потому что тогда бы все команды OS для всех объектов *FILE можно было бы применять друг к другу, а это не так. Создаются эти объекты разными командами, специфичными для конкретного класса. Например, для создания логического файла используется команда CRTLF, а для дисплейного — CRTDSPF. Если бы было по вашему, то существовала бы единая команда типа CRTFILE, которыой бы создавались все варианты объектов данного класса, и логические файл и физические и дисплейные.
При этом, объекты наследуют ряд свойств от базового класса и есть команды применимые ко всем объектам наследующим от *FILE.
Файлы же в свою очередь наследуют от общего класса, и потому WRKOBJ работает не только с файлами но и другими объектами.
Там зависит какие операции. Если только отдавать контент, у вас хорошо все горизонтально масштабируется, актуальность не критична — то проблем нет.
В банках же идет суровый OLTP и деньги. Там так просто на кластер не переведешь.
Конечно, это возможно все перевести на PG и т.п. и большинство шопов или уже перевели, или в процессе или задумываются. Но процесс не быстрый и дорогой.
Почему Альфа упорно держится за i… Была хорошая статья по теме, не могу сейчас найти. Там смысл в психологии менеджмента. Менеджерам спокойнее продолжать платить IBM ежегодно предсказуемую сумму (стоимость владения i относительно невелика), чем рисковать затевать миграцию где сразу нужны большие затраты и успех не гарантирован. В больших инертных организациях менеджмент крайне консервативен в данном вопросе. Пока какой-то внешний фактор явно не припрет (типа санкции), никто ответственность на себя брать не будет.
С точки зрения технической, конечно, открытые технологии и стандарты дают гораздо более высокий уровень гибкости и являются предпочтительными.
Я думаю, надо принципиально решать насчет продолжения использования 5250, а не пытаться искать заместители DDS. DDS отлично делает свое дело. Пример с результатами SQL запроса притянут искусственно. Пользователям никто не даст запускать непредсказуемые запросы. А тех-персоналу все эти «украшательства» не нужны.
Из PRG уже давно можно и в HTTP и во что угодно. Не хочется самим делать — есть куча готовых решений на рынке. Самое известное — profoundlogic.
Хотя сама идея поиграться с возможностью напрямую писать в 5250 поток, конечно, интересная.
Так я же пояснил, что крэш может не быть связан с релизом непосредственно. Большинство ошибок релиза вылавливаются еще на этапе PIV.
И в любом случае, разговор же здесь не про время, а про нахождение ошибки. Вот на проде идут крэши. На тесте они не воспроизводятся. Сложность системы такая, что можно очень долго гадать что там и как и реальный действенный способ понять что происходит — это дать доступ разрабам к проду. А откатить релиз который уже давно в проде — ну, попытайтесь получить разрешение ;-). Когда в релизе изменена методика финансового подсчета чего нибудь там по требованию законодательства и циферки уже 3 недели считаются по новой методе. Откатить бд системы в ядре банка на 3 недели тоже? Удачи ;-). Безумству храбрых поем мы песню, как сказал великий писатель.
Не понимаю суть претензий, они из области этики?
Во-первых, компания вообще никому ничего не должна.
Во-вторых, часто, а в айти особенно, авторы продукта действительно реализуют свое хобби. Не уверен что здесь именно этот случай, но в приципе не вижу проблемы.
В-третьих, за счет бюджета (читай налогоплательщиков) существуют все военные и куча невоенных айти компаний.
Вы не поняли что вам сказали. Себестоимость зависит от объемов. Объемы — от спроса. Поэтому вначале компания может и очень часто будет работать в убыток, чтобы завоевать рынок. Когда возрастут объемы — снизится себестоимость и пойдет прибыль. Сколько на это понадобиться времени — зависит (нередко годы). Но вот чтобы прибыль пошла сразу — это скорее исключение чем правило.
Добавлю, что, конечно, все процессы схожие с описанными выше в компании были, все эскалировалось примерно как вы описали и т.д. Но смысл в том, что ты можешь хоть обписаться процессами и получить 100500 подписей под вашими документами, собрать десятки митингов с менеджерами, админами, разрабабами и т.д. Пока разработчик который знает эту программу не откроет ее в дебаггере на проде и не посмотрит что там в реальности происходит, ничего с места не сдвинется.
Я не говорю, что это требуется в каждом случае. Если ошибка вопроизводится на деве по логам и дампам, ее конечно можно и будут исследовать там. Но бывает что не воспроизводится.
Более того, ошибка может быть никак не связана с последним релизом. Это может быть древний баг который просто ждал своего часа (наступления некоторой комбинации в данных и действиях пользователя и т.п.). Так что вы очень лихо это априори решили, что откат последнего релиза сразу восстановит систему. Далеко не всегда. Вы бесполезно потратите время на откат, который сам по себе уже может быть проблемой, например когда фичи нового релиза — это требования изменившегося законодательства. Кроме того, откат — не всегда быстрый процесс. Он может быть гораздо дольше чем исследовать проблему и быстро установить фикс.
Хех, скажу более, такая ситуация совсем нередко встречается. Разрабам приходится встраивать в софт закладки, чтобы в случае чего на проде быстро и в комфортных условиях посмотреть ошибку. Классический случай, когда некая комбинация действий в клиенте открывает консоль.
Т.е. все эти драконовские меры на самом деле ведут к появлению очень мрачных вещей.
Ага. Да. В той истории, как раз оказалось, внезапно, что можно и из дома залогиниться в прод. И, да, работать через расшаренный терминал через цитрикс предлагали.
Конечно, именно о таком режиме работы по выявлению багов мечтают разработчики :-).
Ребята, зачем разрабу ваш расшаренный ssh терминал через два гейта, если мне нужно подтянуть дебаггер? Разработчику может быть некомфортно работать в терминале, где все настроено строго под выполнение рутинных админских задач по бакапу и т.д. и нет ничего, что разраб использует ежедневно и к чему привык.
По аналогии, я вот свою машину могу вести в любом состоянии с закрытыми глазами кажется. Все действия на автомате, руки сами все делают… Пришлось тут по случаю рулить чужой — я почувствовал себя новичком на площадке. Почему в принципе вы считаете, что админы настолько доверенные люди, что только им позволено, а разрабы могу исключительно через расшаренный экран под пристальным надзором комманды из админов с пальцем на красной кнопке, типа только мышь не туда скользнула — сразу рубим сеть :-).
Насчет вот этих всех авралов… Есть вообще-то трудовое законодательство. И 8-часовой рабочий день. И, потом, проблему можно было спокойно решить в рабочее время.
Потом, вот эти все фантазии, насчет давать внезапно доступ только по инциденту…
Человек в первый раз в жизни зайдет на тот энвайромент — а там все по-другому, чем на его дев машине. Нет привычных комманд, шорткатов, тулов и т.д.
Весь мой опыт говорит — без регулярного опыта работы на проде, сходу, ночью, куча времени будет потрачена на совершенно левые не относящиеся к проблеме вещи.
Ну вот пример, из далекой галактики… В одном банке имеется отдел разработки. Там программисты пишут и кастомизируют банковский софт. Продакшн огорожен со всех сторон, так что только админы имеют к нему полный доступ. Программистов туда не пускают на пушечный выстрел — все каналы перекрыты на уровне файрволов внутренней сети, не говоря уже про логины/пароли. У разрабов отдельная сеть, ибо они, о ужас!, подключаются к интернету со своих десктопов, подкачивают всякие пакеты и обновляют версии IDE, а некоторые даже читают хабр :-). В один прекрасный момент в продакшене начинает крэшится важная программа. Админы информируют, но починить то сами не могут. Привычный вариант «выключить и включить» внезапно не помогает. Предоставляют разрабам лог и дамп, но воспроизвести ошибку не тестовой среде не получается. Понятно, надо разработчикам доступиться до продакшена с нормальными такими правами и своими тулами, чтобы просмотреть, что в этой программе происходит, чтобы быстро понять проблему. Админы — ни в какую, мол, это невозможно никогда! Мы вам не верим и все такое. Ок, начальник отдела разработки пишет докладную мол нам нужен такой то доступ, без него исследовать проблему не представляется возможным, на тесте ошибка не воспроизводится, и со спокойной душой идет домой, рабочий день закончился.
Админы, думая, что они самые умные, обложились тоннами всяких документов по безопасности, которые предписывают «не пущать». Где-то к ночи, проблема доходит до самого верха, где понимают, что если не починить все до утра, проблемы начнутся немаленькие… Дальше, я оставлю читателю домыслить развитие событий :-).
Вы спросите, а почему мол о такой ситуации не позаботились заранее, не продумали процедуру доступа для разрабов к продакшену для решения подобных ситуаций? Ха, так, конечно, о такой ситуации отдел разработки предупреждал и боролся за доступ (все ответы «низзя» заботливо сохранены).
Но админы и безопасники встали стеной и предъявили кучу всяких рекомендаций по безопасности, разграничению доступа и т.п. В том числе и тот аргумент, что если разрабы вдруг получат доступ к проду, то аудиторы этот факт выявят и не одобрят.
К чему я все это пишу? А к тому, что, IMHO, ставить во главу угла безопасность — это путь к краху. Первостепенной, мне кажется, должна быть надежность работы системы, а не бюрократическая составляющая. Конечно, бюрократия нужна. Но дело в приоритетах. Иначе получите вышеописанную ситуацию — с бюрократией все ок, аудиты пройдены, да система упала и починить ее в рамках установленных безопасниками процессов не представляется возможным.
Да, работа конечно веселая, для людей с крепкой нервной системой :-).
Но у меня есть один вопрос, который относится к ИБ вообще.
Где проходит граница между безопасностью и работоспособностью системы/бизнеса?
Т.е. я четко понимаю, что самая безопасная система — это та, которую отключили, ну и в граничном случае еще и сожгли.
Если закрыть все риски по безопасности и проводить жесткий аудит, то можно найти причины остановить любую работающую айти компанию.
Я вижу что на этой теме пасется просто куча больших и мелких бизнесов, толкающих заказчикам всякие решения «сквозного шифрования» и тому подобный «гербалайф».
Админы конечно могут забрать у всех доступ ко всему, все перекрыть, зашифровать, запаковать и опечатать (это по-моему их голубая мечта). Но как в таких условиях работать?
Вот очень верная статья, все правильно подмечено. И про стэндапы и про поощрения.
Вообще, многие адепты аджайла похоже наивно верят, что до аджайла ничего то и не было, кроме сурового вотафола. На самом деле, многие практики отлично работали в 90х. Просто не было всех этих «евангелистов» и прочих «популяризаторов науки», не было хайпа и холиваров вокруг терминологии. Как-то и без них обходились ;-).
Вот именно. При том что «синеоров» хватает. Правда половина в инвалидных креслах и со слуховыми аппаратами, но уступить руководство и уйти на пенсию они не спешат.
На самом деле, история с мэйнфреймами в гос учреждениях, это не показатель какой-то особой экономической эффективности или надежности мэнфреймов. По моей практике, это скорее показатель консервативности и неспособности к изменениям. Если рынок буквально заставляет меняться и улучшаться частный бизнес, то гос бюрократию ничто не жмет в этом плане. Вот потому и продолжают греть атмосферу эти мастодонты. Там где есть конкуренция — с мэйнфреймов съезжают все. Не так давно казалось, что GDS уж точно останутся на мэйнфреймах надолго. А сегодня они практически все от них избавились.
К чему я это говорю? Тут призывают молодежь учить кобол и т.д. Не ведитесь. Такие специалисты требуются только в абсолютно замшелых конторах с людьми пенсионного возраста, которым нужна молодежь чтобы подносить утку. Провести молодые годы в доме престарелых — не лучший выбор.
Ну так и проверяйте его «софт и соушал скилы». Какое отношение к этому имеет сугубо личный субъективный взгляд автора на то, что такое «философия девопс»? При том что сам автор признает что все зыбко и неоднозначно? Обучи людей, организуй процессы, докажи на деле. А зачем мутить эту тему на собеседовании? У кандидата еще может еще 3 собеседования в тот же день и у все свое понимание о том, какой должен быть девопс.
Я вот не понимаю, нанимают человека для определенной инженерской работы, а начинают ему задавать вопросы про философию и «фсе вот это вот».
Причем автор сам признает, что правильных ответов вообщем и нет, все очень зыбко, терминология не устоялась…
Должность это или не должность — какая вообще разница? Тебе шашечки или ехать?
Нанимаешь инженера с конкретным кругом обязанностей — администрить то то и то то, знать такие то системы. Ну так это и спрашивай. Нашел тоже место для удовлетворения своего эго — интервью соискателя. Мол, я понимаю философи девопса, а вы нет.
Иди вот на открытые площадки со своими идеями, доказывай в открытых дискуссиях. Зачем этим заниматься на интервью?
А, нет, так не будет. Цены на продукты провайдеров сетей регулируются государством. Они фиксированы по большей части. Понятно, что о таком сценарии позаботились заранее.
Кроме того, никто не даст БЦ лицензию на предоставление таких услуг. Так что выбор у БЦ будет очень простой: либо пустить в здание лицензированных провайдеров, либо вообще сидеть без интернета. По факту, если БЦ подпадает под стандартные условия, ему проведут на этажи оптику бесплатно. Если нет — он еще и заплатит за строительство сетей.
Ну, а без интернета сейчас его площади мало кого устроят. Так что…
Ну вот у нас в НЗ четко законодательно разделены интернет провайдеры и провайдеры сети. Т.е. владелец сетей не имеет права оказывать услуги провайдера интернет.
Более того, свои услуги он может предоставлять только сертифицированным провайдерам и на одинаковых условиях — все тарифы прозрачны. В результате ситуация с «карманным» провайдером невозможна в принципе.
При этом, объекты наследуют ряд свойств от базового класса и есть команды применимые ко всем объектам наследующим от *FILE.
Файлы же в свою очередь наследуют от общего класса, и потому WRKOBJ работает не только с файлами но и другими объектами.
В банках же идет суровый OLTP и деньги. Там так просто на кластер не переведешь.
Конечно, это возможно все перевести на PG и т.п. и большинство шопов или уже перевели, или в процессе или задумываются. Но процесс не быстрый и дорогой.
Почему Альфа упорно держится за i… Была хорошая статья по теме, не могу сейчас найти. Там смысл в психологии менеджмента. Менеджерам спокойнее продолжать платить IBM ежегодно предсказуемую сумму (стоимость владения i относительно невелика), чем рисковать затевать миграцию где сразу нужны большие затраты и успех не гарантирован. В больших инертных организациях менеджмент крайне консервативен в данном вопросе. Пока какой-то внешний фактор явно не припрет (типа санкции), никто ответственность на себя брать не будет.
С точки зрения технической, конечно, открытые технологии и стандарты дают гораздо более высокий уровень гибкости и являются предпочтительными.
Из PRG уже давно можно и в HTTP и во что угодно. Не хочется самим делать — есть куча готовых решений на рынке. Самое известное — profoundlogic.
Хотя сама идея поиграться с возможностью напрямую писать в 5250 поток, конечно, интересная.
И в любом случае, разговор же здесь не про время, а про нахождение ошибки. Вот на проде идут крэши. На тесте они не воспроизводятся. Сложность системы такая, что можно очень долго гадать что там и как и реальный действенный способ понять что происходит — это дать доступ разрабам к проду. А откатить релиз который уже давно в проде — ну, попытайтесь получить разрешение ;-). Когда в релизе изменена методика финансового подсчета чего нибудь там по требованию законодательства и циферки уже 3 недели считаются по новой методе. Откатить бд системы в ядре банка на 3 недели тоже? Удачи ;-). Безумству храбрых поем мы песню, как сказал великий писатель.
Во-первых, компания вообще никому ничего не должна.
Во-вторых, часто, а в айти особенно, авторы продукта действительно реализуют свое хобби. Не уверен что здесь именно этот случай, но в приципе не вижу проблемы.
В-третьих, за счет бюджета (читай налогоплательщиков) существуют все военные и куча невоенных айти компаний.
Я не говорю, что это требуется в каждом случае. Если ошибка вопроизводится на деве по логам и дампам, ее конечно можно и будут исследовать там. Но бывает что не воспроизводится.
Более того, ошибка может быть никак не связана с последним релизом. Это может быть древний баг который просто ждал своего часа (наступления некоторой комбинации в данных и действиях пользователя и т.п.). Так что вы очень лихо это априори решили, что откат последнего релиза сразу восстановит систему. Далеко не всегда. Вы бесполезно потратите время на откат, который сам по себе уже может быть проблемой, например когда фичи нового релиза — это требования изменившегося законодательства. Кроме того, откат — не всегда быстрый процесс. Он может быть гораздо дольше чем исследовать проблему и быстро установить фикс.
Т.е. все эти драконовские меры на самом деле ведут к появлению очень мрачных вещей.
Конечно, именно о таком режиме работы по выявлению багов мечтают разработчики :-).
Ребята, зачем разрабу ваш расшаренный ssh терминал через два гейта, если мне нужно подтянуть дебаггер? Разработчику может быть некомфортно работать в терминале, где все настроено строго под выполнение рутинных админских задач по бакапу и т.д. и нет ничего, что разраб использует ежедневно и к чему привык.
По аналогии, я вот свою машину могу вести в любом состоянии с закрытыми глазами кажется. Все действия на автомате, руки сами все делают… Пришлось тут по случаю рулить чужой — я почувствовал себя новичком на площадке. Почему в принципе вы считаете, что админы настолько доверенные люди, что только им позволено, а разрабы могу исключительно через расшаренный экран под пристальным надзором комманды из админов с пальцем на красной кнопке, типа только мышь не туда скользнула — сразу рубим сеть :-).
Насчет вот этих всех авралов… Есть вообще-то трудовое законодательство. И 8-часовой рабочий день. И, потом, проблему можно было спокойно решить в рабочее время.
Потом, вот эти все фантазии, насчет давать внезапно доступ только по инциденту…
Человек в первый раз в жизни зайдет на тот энвайромент — а там все по-другому, чем на его дев машине. Нет привычных комманд, шорткатов, тулов и т.д.
Весь мой опыт говорит — без регулярного опыта работы на проде, сходу, ночью, куча времени будет потрачена на совершенно левые не относящиеся к проблеме вещи.
Админы, думая, что они самые умные, обложились тоннами всяких документов по безопасности, которые предписывают «не пущать». Где-то к ночи, проблема доходит до самого верха, где понимают, что если не починить все до утра, проблемы начнутся немаленькие… Дальше, я оставлю читателю домыслить развитие событий :-).
Вы спросите, а почему мол о такой ситуации не позаботились заранее, не продумали процедуру доступа для разрабов к продакшену для решения подобных ситуаций? Ха, так, конечно, о такой ситуации отдел разработки предупреждал и боролся за доступ (все ответы «низзя» заботливо сохранены).
Но админы и безопасники встали стеной и предъявили кучу всяких рекомендаций по безопасности, разграничению доступа и т.п. В том числе и тот аргумент, что если разрабы вдруг получат доступ к проду, то аудиторы этот факт выявят и не одобрят.
К чему я все это пишу? А к тому, что, IMHO, ставить во главу угла безопасность — это путь к краху. Первостепенной, мне кажется, должна быть надежность работы системы, а не бюрократическая составляющая. Конечно, бюрократия нужна. Но дело в приоритетах. Иначе получите вышеописанную ситуацию — с бюрократией все ок, аудиты пройдены, да система упала и починить ее в рамках установленных безопасниками процессов не представляется возможным.
Но у меня есть один вопрос, который относится к ИБ вообще.
Где проходит граница между безопасностью и работоспособностью системы/бизнеса?
Т.е. я четко понимаю, что самая безопасная система — это та, которую отключили, ну и в граничном случае еще и сожгли.
Если закрыть все риски по безопасности и проводить жесткий аудит, то можно найти причины остановить любую работающую айти компанию.
Я вижу что на этой теме пасется просто куча больших и мелких бизнесов, толкающих заказчикам всякие решения «сквозного шифрования» и тому подобный «гербалайф».
Админы конечно могут забрать у всех доступ ко всему, все перекрыть, зашифровать, запаковать и опечатать (это по-моему их голубая мечта). Но как в таких условиях работать?
Вообще, многие адепты аджайла похоже наивно верят, что до аджайла ничего то и не было, кроме сурового вотафола. На самом деле, многие практики отлично работали в 90х. Просто не было всех этих «евангелистов» и прочих «популяризаторов науки», не было хайпа и холиваров вокруг терминологии. Как-то и без них обходились ;-).
К чему я это говорю? Тут призывают молодежь учить кобол и т.д. Не ведитесь. Такие специалисты требуются только в абсолютно замшелых конторах с людьми пенсионного возраста, которым нужна молодежь чтобы подносить утку. Провести молодые годы в доме престарелых — не лучший выбор.
Причем автор сам признает, что правильных ответов вообщем и нет, все очень зыбко, терминология не устоялась…
Должность это или не должность — какая вообще разница? Тебе шашечки или ехать?
Нанимаешь инженера с конкретным кругом обязанностей — администрить то то и то то, знать такие то системы. Ну так это и спрашивай. Нашел тоже место для удовлетворения своего эго — интервью соискателя. Мол, я понимаю философи девопса, а вы нет.
Иди вот на открытые площадки со своими идеями, доказывай в открытых дискуссиях. Зачем этим заниматься на интервью?
Кроме того, никто не даст БЦ лицензию на предоставление таких услуг. Так что выбор у БЦ будет очень простой: либо пустить в здание лицензированных провайдеров, либо вообще сидеть без интернета. По факту, если БЦ подпадает под стандартные условия, ему проведут на этажи оптику бесплатно. Если нет — он еще и заплатит за строительство сетей.
Ну, а без интернета сейчас его площади мало кого устроят. Так что…
Более того, свои услуги он может предоставлять только сертифицированным провайдерам и на одинаковых условиях — все тарифы прозрачны. В результате ситуация с «карманным» провайдером невозможна в принципе.