Айтишники на пенсии

[zVlad]

1) намедни я говорил о средних значениях, которые таки да ниже секунды получаются. Для контороля SLA определены наиболее критичные транзакции, которые выполняются роботами с каждой location клиента (их больше десятка) по времени и замеряется время выполнения. Показания этих роботов и используется для SLA. ОТ ПОЛУСЕКУНДЫ ДО СЕКУНДЫ ЭТО средние опять же значениям с пяти серверов приложений (CICS), которые выполняются на продакшн (на МФ) одновременно и по которым разбросаны пользователи этого приложения (исходя из их территориального нахождения). Да разница между ними существенна на мой взгляд и это как-то объясняется, но я не знаю как. Как то так.

Давайте посмотрим, что вы говорили
Среднее время выполнения тех наших 2.5 млн. транзакций не более одной секунды. Учет этого времени ведется по пяти различным группам и среднее время в группах от 0.5 сек до одной сек. Пусть будет 1 секунда.
ок, здесь нет ничего про "за превышение порога в 1 сек карают" - либо это было в другом месте, либо это у меня глюк. но тут есть важная деталь - среднее вычисляется по группам. т.е. не может быть такого, что одна транзакция элементарна и выполняется в миллисекунды, а другая - сложна и выполняется долго, а среднее около секунды. т.е. у вас есть транзакции, которые одного порядка сложности, выполняются меньше, чем за секунду, но иногда - 10+ минут. это песец, товарищи
...

Вас похоже ввело в заблуждение образования упомянутых груп. Я говорил об этом, повторю, это не группы транзакций, это групы людей, выполняющих в принципе одинаковые наборы транзакций просто работающих с разных крупных location: head office, station 1, station 2, и т.д

А с этим: "..т.е. не может быть такого, что одна транзакция элементарна и выполняется в миллисекунды, а другая - сложна и выполняется долго" все в точности до наоборот. Именно так оно и есть на самом деле что все транзакции разные и именно из-за их большой разницы они выполняются разное время, или иначе требует разный обьем ресурсов для своего выполнения. Большенство выполняются значительно меньше секунды и в среднем получается от .5 до 1. в разных группах.

Для контроля SLA определены наиболее критичные транзакции, которые выполняются роботами с каждой location клиента (их больше десятка) по времени и замеряется время выполнения. В число этих транзакций "длинные" не входят.

"длинными", кстати, делают транзакции некоторые пользователи, я уже это отмечал, тем что не задают диапазоны поиска, предлагаемые им. Приложение написано так что в этом случае рассматривается весь диапазон: от минимума до максимума. Пользователей учат этим обятзательно пользоваться, но они поступают иначе, не все но все таки есть. После сортировки они в начале списка имеют то что им надо: последние события. То что при этом БД строит весь набор событий с начала эксплуатации приложения их не волнует и видимо время вполнения такой работы не так уж и велико, иначе они бы задавали границы более разумно.

Вот кстати свеженькая гистограмка (специально для Вас, правда за субботу, не самый напряженный день, но это в данном случае не так важно). 18 транзакций в этой группе (одной из пяти, в субботу с 7:00 до 7:30) выполнялись дольше 4 секунд:

Code: Select all

                                        ----------RESPONSE TIME DISTRIBUTION----------
    ----TIME----    --NUMBER OF TRANSACTIONS--    -------PERCENT-------  0    10   20   30   40   50   60   70   80   90   100
    HH.MM.SS.TTT    CUM TOTAL        IN BUCKET    CUM TOTAL   IN BUCKET  !....!....!....!....!....!....!....!....!....!....!
 <  00.00.00.500         1841             1841         78.2        78.2  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 <= 00.00.00.600         2046              205         87.0         8.7  >>>>>
 <= 00.00.00.700         2131               85         90.6         3.6  >>>
 <= 00.00.00.800         2164               33         92.0         1.4  >
 <= 00.00.00.900         2195               31         93.3         1.3  >
 <= 00.00.01.000         2214               19         94.1         0.8  >
 <= 00.00.01.100         2232               18         94.9         0.8  >
 <= 00.00.01.200         2244               12         95.4         0.5  >
 <= 00.00.01.300         2254               10         95.8         0.4  >
 <= 00.00.01.400         2265               11         96.3         0.5  >
 <= 00.00.01.500         2272                7         96.6         0.3  >
 <= 00.00.02.000         2293               21         97.5         0.9  >
 <= 00.00.04.000         2335               42         99.2         1.8  >>
 >  00.00.04.000         2353               18          100         0.8  >

Эта информация, кстати, побочный результат работы WLM, используется для управления процессами с целью достижения качества процессов: 90% транзакций за меньше чем 1 секунда (последняя строка):

Code: Select all

Service Class Name . . . . . :,CICS    ,
Description  . . . . . . . . .,CICS Transactions xNG1          ,
Workload Name  . . . . . . . .,ONLINES ,,(name or ?) ,
Base Resource Group  . . . . .,________,,(name or ?) ,
Cpu Critical . . . . . . . . .,YES,,     (YES or NO)  ,

Specify BASE GOAL information. Action Codes: I=Insert new period,,    ,
E=Edit period, D=Delete period.,                                      ,
,
       ,--,Period,-- ,-------------------,Goal,-------------------
Action ,# ,Duration  ,Imp. ,Description
 ,__,  ,_,,_________, ,_,  ,________________________________________,
 ,__,  ,1,,_________, ,2,  ,90% complete within 00:00:01.000        ,

[zVlad]

Добавление ресурсов (серверов) это не только новые сервера, но и новое сетевое оборудование (и много чего другого), которое надо не только добавлять для обеспечения производительности, но для надежности дублировать. А потом получается простой из-за коммуникаций как недавно в BritishAirways.

Наглости и самоуверенности вам не занимать (попробуйте карьеру в Гербалайф).
British airways используют МФ и все равно виноваты другие ?!
У них был перебой в работе ровно из-за того, что их система оказалась не распределённая. Если бы у них был резервный датацентр, то в первом хоть ядерный взрыв произойди, все было бы нормально.

За незаслуженные обвинения Вам придется извиниться.

Пока я не видел доказательств что инцидент был именно с МФ. Заметка в стенгазете, где было слово "mainframe" без связи с инцидентом это не доказательство. Если у Вас что-нибудь существенно, плеасе. Я не отрицаю, кстати, что это могли бы быть МФ. Были МФ это тоже интересно было бы разобрать, но разобрать со всей информацией на руках. Которой мы вряд ли будем располагать. В ИТ не принято выворачиваться на изнанку.

Мои рассуждения как раз на том стрились что в случае МФ и в случае серьезного их применения, а BritishAirways это серьезно, всегда есть DR scenario, и если бы менеджеры BA поняли что система будет недоступной долго то могли бы декларировать DR и подняться без проблем на DR site.

У них был перебой в работе из-за системы энергоснабжения, перед которым все платформы равны. А Ваши любимые распределенные системы обычно оперируют терминoм HA - High Availability. В этом случае ставится запасной сервер рядом (в том же строении) с основным и в случае проблем с ПО основного (система упала, БД, etc...) работа переводится на запасной. Надеюсь Вам понятно что от потери электричества во всем строении эта мера не спасает. Упали оба, и основной и запасной серевера.

Я не утвержадаю что в распределенных системах невозможен DR scenario. Такое есть в нашей конторе. Но тесты DR с распределенными системами у нас редко проходят без проблем, очень редко. А в Феврале этого года мы дотеcтировались на распределенных системах до штрафных санкций от нашего клиента. Тесты DR с МФ за 17 лет моей работы в этой конторе ни разу не были неуспешными, ни разу. Было время мы по два раза в год тестировались.

[АццкоМото]

В этом случае ставится запасной сервер рядом (в том же строении) с основным и в случае проблем с ПО основного (система упала, БД, etc...) работа переводится на запасной. Надеюсь Вам понятно что от потери электричества во всем строении эта мера не спасает. Упали оба, и основной и запасной серевера.

Никто и никогда так не делает для серьезных применений. Мало того, что нормальные датацентры имеют резервные генераторы, которые при обвале питания заводятся за секунды и могут работать днями-неделями, функциональность принято дублировать в нескольких географически разнесенных датацентрах. курить можно тут, например: https://www.ibm.com/cloud-computing/blu ... ta-centers

[АццкоМото]

АццкоМото, дорогой, расскажите поподробнее. Вы должны понять как мне начинающему преподавателю в этой сфере это важно может быть.
Сколько времени потратили, какова была цель изучения, как узучали: самостоятельно или с инструктором, была ли достигнута цель и довелось ли попрактитоваться с этими системами, в каких ролях. Что помнится до сих пор. Примерно в этом ключе, пожалуйста. Если что захотите добавить, еще лучше, отдельное спасибо. Если не хотите это обсуждать публично - в личку.

Да что там рассказывать-то? В деццве у меня был доступ к библиотеке РАН, а там была литература, которая иначе была практически недоступна. В том числе талмуд по операционным системам, в оригинале и на английском. Да, тогда это было жутко интересно - когда вокруг тебя всякие Правецы, коммодоры и вершина - IBM PC под MS-DOS, даже про защищенную память читаешь, как про космос, а виртуализация вообще не помещается в мозг как концепт. Все самостоятельно, конечно, по началу - исключительно в теории. Немного позже попробовал немного 360, но не всерьез, к тому времени уже был 386 процессор и жизнь взбурлила именно там.
До сих пор помнится разве что обложка книги - я бы ее даже купил в качестве сувенира, если бы нашел сейчас

[zVlad]

В этом случае ставится запасной сервер рядом (в том же строении) с основным и в случае проблем с ПО основного (система упала, БД, etc...) работа переводится на запасной. Надеюсь Вам понятно что от потери электричества во всем строении эта мера не спасает. Упали оба, и основной и запасной серевера.

Никто и никогда так не делает для серьезных применений. Мало того, что нормальные датацентры имеют резервные генераторы, которые при обвале питания заводятся за секунды и могут работать днями-неделями, функциональность принято дублировать в нескольких географически разнесенных датацентрах. курить можно тут, например: https://www.ibm.com/cloud-computing/blu ... ta-centers

Не думал что надо будет разяснять. Когда я говорю DR scenario я имею в виду именно это: "географически разнесенныeх датацентры". Курю уже это семьнадцать лет.
Вопрос остается тем же: почему BA не возпользовался "географически разнесенных датацентрах"? Ваша ссылка ответить на этот вопрос никак не помогает.

[zVlad]

АццкоМото, дорогой, расскажите поподробнее. Вы должны понять как мне начинающему преподавателю в этой сфере это важно может быть.
Сколько времени потратили, какова была цель изучения, как узучали: самостоятельно или с инструктором, была ли достигнута цель и довелось ли попрактитоваться с этими системами, в каких ролях. Что помнится до сих пор. Примерно в этом ключе, пожалуйста. Если что захотите добавить, еще лучше, отдельное спасибо. Если не хотите это обсуждать публично - в личку.

Да что там рассказывать-то? В деццве у меня был доступ к библиотеке РАН, а там была литература, которая иначе была практически недоступна. В том числе талмуд по операционным системам, в оригинале и на английском. Да, тогда это было жутко интересно - когда вокруг тебя всякие Правецы, коммодоры и вершина - IBM PC под MS-DOS, даже про защищенную память читаешь, как про космос, а виртуализация вообще не помещается в мозг как концепт. Все самостоятельно, конечно, по началу - исключительно в теории. Немного позже попробовал немного 360, но не всерьез, к тому времени уже был 386 процессор и жизнь взбурлила именно там.
До сих пор помнится разве что обложка книги - я бы ее даже купил в качестве сувенира, если бы нашел сейчас

Да, не густо, но все равно спасибо. Как именно пробовали 360 не припомните? В общих словах хотя бы.

[АццкоМото]

В этом случае ставится запасной сервер рядом (в том же строении) с основным и в случае проблем с ПО основного (система упала, БД, etc...) работа переводится на запасной. Надеюсь Вам понятно что от потери электричества во всем строении эта мера не спасает. Упали оба, и основной и запасной серевера.

Никто и никогда так не делает для серьезных применений. Мало того, что нормальные датацентры имеют резервные генераторы, которые при обвале питания заводятся за секунды и могут работать днями-неделями, функциональность принято дублировать в нескольких географически разнесенных датацентрах. курить можно тут, например: https://www.ibm.com/cloud-computing/blu ... ta-centers

Не думал что надо будет разяснять. Когда я говорю DR scenario ya imeyu v vidu imenno e'to: "географически разнесенныeх датацентры". Купю уже это семьнадцать лет.
Вопрос остается тем же: почему BA не возпользовался "географически разнесенных датацентрах"? Ваша ссылка ответить на этот вопрос никак не помогает.

я вообще ни слова про ВА не сказал. просто у вас какое-то странное представление о мире за пределами МФ. типа там ставят два самосборных сервака, основной и запасной, и фтыкают в одну розетку через китайский тройник. это не так.

что случилось с ВА я понятия не имею

[АццкоМото]

АццкоМото, дорогой, расскажите поподробнее. Вы должны понять как мне начинающему преподавателю в этой сфере это важно может быть.
Сколько времени потратили, какова была цель изучения, как узучали: самостоятельно или с инструктором, была ли достигнута цель и довелось ли попрактитоваться с этими системами, в каких ролях. Что помнится до сих пор. Примерно в этом ключе, пожалуйста. Если что захотите добавить, еще лучше, отдельное спасибо. Если не хотите это обсуждать публично - в личку.

Да что там рассказывать-то? В деццве у меня был доступ к библиотеке РАН, а там была литература, которая иначе была практически недоступна. В том числе талмуд по операционным системам, в оригинале и на английском. Да, тогда это было жутко интересно - когда вокруг тебя всякие Правецы, коммодоры и вершина - IBM PC под MS-DOS, даже про защищенную память читаешь, как про космос, а виртуализация вообще не помещается в мозг как концепт. Все самостоятельно, конечно, по началу - исключительно в теории. Немного позже попробовал немного 360, но не всерьез, к тому времени уже был 386 процессор и жизнь взбурлила именно там.
До сих пор помнится разве что обложка книги - я бы ее даже купил в качестве сувенира, если бы нашел сейчас

Да, не густо, но все равно спасибо. Как именно пробовали 360 не припомните? В общих словах хотя бы.

В ИАПУ стояли совеццкие аналоги ойбеэмов (ЕС? я уже даже этого не помню) и пшиздрюков иногда пускали на них попрограммировать, иногда даже какие-то лекции читали. ощущения странные, вроде и круто, но при этом таааак кондово, что пипец

повторюсь, тогда уже началась эра ПК и с ними было интереснее

[zVlad]

В этом случае ставится запасной сервер рядом (в том же строении) с основным и в случае проблем с ПО основного (система упала, БД, etc...) работа переводится на запасной. Надеюсь Вам понятно что от потери электричества во всем строении эта мера не спасает. Упали оба, и основной и запасной серевера.

Никто и никогда так не делает для серьезных применений. Мало того, что нормальные датацентры имеют резервные генераторы, которые при обвале питания заводятся за секунды и могут работать днями-неделями, функциональность принято дублировать в нескольких географически разнесенных датацентрах. курить можно тут, например: https://www.ibm.com/cloud-computing/blu ... ta-centers

Не думал что надо будет разяснять. Когда я говорю DR scenario ya imeyu v vidu imenno e'to: "географически разнесенныeх датацентры". Купю уже это семьнадцать лет.
Вопрос остается тем же: почему BA не возпользовался "географически разнесенных датацентрах"? Ваша ссылка ответить на этот вопрос никак не помогает.

я вообще ни слова про ВА не сказал. просто у вас какое-то странное представление о мире за пределами МФ. типа там ставят два самосборных сервака, основной и запасной, и фтыкают в одну розетку через китайский тройник. это не так.

что случилось с ВА я понятия не имею

Вы взяли мою цитату для Ваших нравоучений именно из разговора о BA. Не заметили?
BA это не ИБМ BluMix, но и не с Луны свалились люди работающие в BA IT. Согласны? BA IT допустила 3-х дневный хаос со своими рейсами. Возражать не будите? Почему это оказалось возможным? Потому что они использовали МФ говорит oshibla_rezidenta. А Вы говорите потому что BluMix. Или как у "Уральских пельменей" - потому что гладиолусы.

[zVlad]

...
В ИАПУ стояли совеццкие аналоги ойбеэмов (ЕС? я уже даже этого не помню) и пшиздрюков иногда пускали на них попрограммировать, иногда даже какие-то лекции читали. ощущения странные, вроде и круто, но при этом таааак кондово, что пипец

повторюсь, тогда уже началась эра ПК и с ними было интереснее

Понятно. Наверное на Вашем месте у меня были бы такие же впечатления. Но я успел зацепиться за серьезные направления и на серьезном уровне до появления ПК. Чему, честно, очень рад. Вы должно быть понимаете что у меня достаточно практики в обоих мирах чтобы сравнивать предметно.

[АццкоМото]

Вы взяли мою цитату для Ваших нравоучений именно из разговора о BA. Не заметили?

я вырезал ровно ту часть вашего длинного поста, по которой у меня было, что сказать, и в этой цитате нет ни слова про ВА, не заметили?

BA это не ИБМ BluMix, но и не с Луны свалились люди работающие в BA IT. Согласны? BA IT допустила 3-х дневный хаос со своими рейсами. Возражать не будите? Почему это оказалось возможным? Потому что они использовали МФ говорит oshibla_rezidenta. А Вы говорите потому что BluMix. Или как у "Уральских пельменей" - потому что гладиолусы.

Как я уже говорил, я ничего не знаю про ВА. Поэтому не могу ни согласиться, ни оспаривать. И, кстати, я ничего не говорил про БлюМикс в контексте ВА. я просто привел ссылку на характеристики современных датацентров, их количество у одного случайно выбранного оператора и географический разброс. можно было бы выбрать rackspace, например. тот же хрен в другой руке

[АццкоМото]

Понятно. Наверное на Вашем месте у меня были бы такие же впечатления. Но я успел зацепиться за серьезные направления и на серьезном уровне до появления ПК. Чему, честно, очень рад. Вы должно быть понимаете что у меня достаточно практики в обоих мирах чтобы сравнивать предметно.

Нет, я должно быть, понимаю, что 1) практики вне МФ у вас недостаточно и 2) на МФ вы админ, т.е. понимаете МФ с очень специфичной точки зрения: вас заботит, чтобы работало что-то, созданное другими, но не очень заботит, как именно оно работает и почему так

[zVlad]

Понятно. Наверное на Вашем месте у меня были бы такие же впечатления. Но я успел зацепиться за серьезные направления и на серьезном уровне до появления ПК. Чему, честно, очень рад. Вы должно быть понимаете что у меня достаточно практики в обоих мирах чтобы сравнивать предметно.

Нет, я должно быть, понимаю, что 1) практики вне МФ у вас недостаточно и 2) на МФ вы админ, т.е. понимаете МФ с очень специфичной точки зрения: вас заботит, чтобы работало что-то, созданное другими, но не очень заботит, как именно оно работает и почему так

Я заметил что у Вас отношение к админ-ам, как бы сказать, не МФ-ское. В самом деле откуда ему быть МФ-ским если Ваше знакомство с МФ и их ОС более чем шапочное.
На Windows, и Unix админы такие как Вы говорите. Это мне известно и я этот взгляд с Вами полностью разделяю. На Unix/Windows програмисты это элита. На МФ дела обстоят с точностью до наоборот: элита это системные програмисты, так правильно называют z/OS админов. Системные програмисты помогают програмистам правильно использовать ОС, разьясняют те или иные сложные возможности OS. Многие из этих возможностей используются без прямых обращений програмистов в програмах и следовательно являются неожиданностью для програмиста. Тут приходит на помощь системный програмист. Програмисты зачастую мало знают о z/OS и не могут сами писать еффективные програмы без помощи системщиков. Так что, поверьте, мне достаточно интересно выполнять роль "admina" на МФ. И Вам бы, я уверен, было бы интересно случись так что Вы оказались на МФ в роли "админа".
У меня на этот счет есть такая фраза: "Windows/Unix написаны програмистами для програмистов, a z/OS системными програмистами для програмистов."

[АццкоМото]

Понятно. Наверное на Вашем месте у меня были бы такие же впечатления. Но я успел зацепиться за серьезные направления и на серьезном уровне до появления ПК. Чему, честно, очень рад. Вы должно быть понимаете что у меня достаточно практики в обоих мирах чтобы сравнивать предметно.

Нет, я должно быть, понимаю, что 1) практики вне МФ у вас недостаточно и 2) на МФ вы админ, т.е. понимаете МФ с очень специфичной точки зрения: вас заботит, чтобы работало что-то, созданное другими, но не очень заботит, как именно оно работает и почему так

Я заметил что у Вас отношение к админ-ам, как бы сказать, не МФ-ское. В самом деле откуда ему быть МФ-ским если Ваше знакомство с МФ и их ОС более чем шапочное.
На Windows, и Unix админы такие как Вы говорите. Это мне известно и я этот взгляд с Вами полностью разделяю. На Unix/Windows програмисты это элита. На МФ дела обстоят с точностью до наоборот: элита это системные програмисты, так правильно называют z/OS админов. Системные програмисты помогают програмистам правильно использовать ОС, разьясняют те или иные сложные возможности OS. Многие из этих возможностей используются без прямых обращений програмистов в програмах и следовательно являются неожиданностью для програмиста. Тут приходит на помощь системный програмист. Програмисты зачастую мало знают о z/OS и не могут сами писать еффективные програмы без помощи системщиков. Так что, поверьте, мне достаточно интересно выполнять роль "admina" на МФ. И Вам бы, я уверен, было бы интересно случись так что Вы оказались на МФ в роли "админа".
У меня на этот счет есть такая фраза: "Windows/Unix написаны програмистами для програмистов, a z/OS системными програмистами для програмистов."

Дорогой zVlad. В моем мире программисты - это люди, которые пишут программы. Не пытайтесь меня убедить, что в мире МФ все по-пругому

[oshibka_residenta]

Добавление ресурсов (серверов) это не только новые сервера, но и новое сетевое оборудование (и много чего другого), которое надо не только добавлять для обеспечения производительности, но для надежности дублировать. А потом получается простой из-за коммуникаций как недавно в BritishAirways.

Наглости и самоуверенности вам не занимать (попробуйте карьеру в Гербалайф).
British airways используют МФ и все равно виноваты другие ?!
У них был перебой в работе ровно из-за того, что их система оказалась не распределённая. Если бы у них был резервный датацентр, то в первом хоть ядерный взрыв произойди, все было бы нормально.

Мои рассуждения как раз на том стрились что в случае МФ и в случае серьезного их применения, а BritishAirways это серьезно, всегда есть DR scenario, и если бы менеджеры BA поняли что система будет недоступной долго то могли бы декларировать DR и подняться без проблем на DR site.

У них был перебой в работе из-за системы энергоснабжения, перед которым все платформы равны. А Ваши любимые распределенные системы обычно оперируют терминoм HA - High Availability. В этом случае ставится запасной сервер рядом (в том же строении) с основным и в случае проблем с ПО основного (система упала, БД, etc...) работа переводится на запасной. Надеюсь Вам понятно что от потери электричества во всем строении эта мера не спасает. Упали оба, и основной и запасной серевера.

DR не имеет никакого отношения к МФ. И я же вроде бы ясно написал - см. выделенное выше. У нас, к примеру, более одного датацентра работают одновременно. Поэтому в случае сбоя ( или штатного выключения for maintenance в одном иза датацентров) никакой "DR декларировать" не надо. С точки зрения клиентов все продолжает работать 24х7