А как же звук хэндшейка, обрыв на последних байтах долгожданного пакета с эхой, поинтовка и пиво с сисопом?! А BBS модели чебурашка, которая могла жить в любой телефонной будке? Скупая слеза и олдскулы свело.
Начинать надо с того, что сам отчет-то правильно сформировали или просто табличку нашли? С реальными выплатами сравнили хотя бы? Если там 115+ деньги получает - агента Малдера послали?
Ну есть поле в БД жив/нет и что? Вон наш ПФР пытается заставить определить это состояние банки, чтобы они мониторили активность клиента, получающего соцвыплаты. Что они потом с этим делают - хз.
А мне интересно, откуда взялся график? Его собирали "на всякую случку" или был повод ранее? Если первое, то нужно просматривать результаты мониторинга и отлавливать аномалии по всем собираемым показателям, при чем и на тестовых средах, что наиболее правильно, и при раскатке на фокусных группах особенно. А если второе, то нужно еще и сделать оргвыводы.
Но если данный подход под микросервис, под которым БД на 3 таблицы в сотню строк - да пофиг, там и sql нафиг. Но "когда у тебя в руках молоток, весь мир - гвозди".
Для промышленного применения, когда у тебя БД нагрузкой, каждый запрос умножается на число его вызовов. Исправить ошибки проектирования сложнее чем ошибку в днк проектировщика. На заре появления реляционных БД инженеры думали головой. Например, static(embedded) sql и никаких инъекций, и сервер не занимается компиляциями однотипных запросов, стоимость которых на порядок выше цены их исполнения, и никаких вопросов "кто написал этот скуль?! Сервер лег!", и безопам счастье, никаких юзеров, одни спузы.
Автогенераторы кода для БД давно существуют для компенсации скиллов разработчиков. Прототипировать годиться. Но когда такой продукт идет в бой, наступает прозрение. Но переписывать уже работающий код...
Если бы еще инженеры в далеком 2000 не сдались с SQL SP, то не было бы антипаттерна про бизнес-логику в БД... :)
Все банки подключены к ГИС ГМП. Это коммуналка, штрафы, судебные и тп. Получить из госсистемы начисления можно по ИНН, который банк знает. И банк обязан проверить наличие и статус в ГИС ГМП, если в платежке есть поле УИД (22, и, кто бы мог подумать, оно же теперь для ЭДО с ФНС после перехода на ЕНС, чтоб ИТ не скучали) - чтобы избежать ситуации, когда два банка (авто)платеж сделают по одному начислению.
Так почему бы не помочь клиенту комфортно потратить деньги на неприятные вещи типа штрафа, предзаполнив за него правильно все поля?
Любая нештатная ситуация сначала возникает первый раз. Например, скорость мониторинга могла не успеть за метрикой или создание такой ситуации самой системой мониторинга. Но больше вероятность человеческого фактора, в том числе из лучших побуждений, например при невозможности воспроизвести ошибку на тесте приходиться рисковать на бою - сам так делал :)
Япония - работает, сильно упрощая процесс перевода. Потому что перекинуть деньги иным способом - это обязательный поход в Банк по предварительной записи с доказательными бумажками и 2-3 недели на сам перевод, у Примсоц чуть быстрее в пару банков.
Идея класс! Но, как пользователь со стажем, задам вопрос - колебания монитора на столь длинном рычаге при движении как-то решены? При долгом сидении, даже в сверхудобном положении,что-то затекает и организм начинает это компенсировать - мы меняем положение, трясем ногой и пр. Просто при работе с клавиатурой есть колебания весьма монолитного стола. Я был вынужден был заменить кронштейн для монитора, который крепился к столу, на настенный вариант. В данной конструкции, как я вижу, колебания будут напрямую передаваться на монитор. Какой был кошмар в свое время из-за колебания решетки на тринитронах...
Как погруженный в тему - не всегда можно предвидеть. Имея весьма нескромный опыт в кровавом энтерпрайзе и построив эшелонированную оборону от разработки до деплоя на прод, несколько раз ловил epic fail.
В качестве примера - была задача по ограничению доступной инфы на экране признаку VIP. VIP'ов было пара сотен, что на фоне миллионов клиентов даже в пределы погрешности не укладывалось. Задачку примитивная, скинули джуну, по феншую фичу даже протестировали на паре офисов и забыли до отмашки заказчиком. Через пару месяцев вместе с глобальным обновлением включили в релиз - как крыжик в настройках...
Джун, ему простительно, реализовал прекрасно: на каждый (ты вдруг VIP'ом стал внезапно) got/lost focus элемента формы проверка через select * from vip, дальше поиск по массиву уже на клиенте...
В форме, центральной, было несколько десятков закладок, пара сотен статических и, в зависимости от, еще минимум сотня динамических элементов. А в момент открытия формы, как мы потом узнали, каждый (!) элемент генерил эти 2 события. И в понедельник утром > 5 тыс. ничего не подозревающих пользователей пришли на работу. И не могли открыть форму, приложение "висело", они его срубали и открывали заново. Восточные регионы успели, а следующие часовые пояса уже нет, что внесло свои коррективы в понимание проблемы. Мы докидывали сервера приложений, которые принимались переваривать все новые сессии пользователей, а старые никуда не девались, пока не дорабатывали до конца или мы не перегружали сервак. Между БД и серверами приложений гнался немеренный траффик. К БД было подключено несколько десятков и других приложений, и там тоже началась деградация.
Тем, кто не очень в теме БД, простой select из базы в таком виде грубо: declare stmt/open cursor/fetch 200+ rows/close cursor, каждое действие это несколько пакетов, каждый фетч страница в 4Кб, умноженное на число строк в таблице - 200+ и умноженное на 2*300 раз за контрол на форме на каждого пользователя=5000 и каждую зависшую сессию - умножить еще на 2. И все это в единицу времени. "Ватага зайцев мочит льва."
Мы ddos-или собственную инфру. И самое главное, не понимали причину, поднимали новые сервера => создавали все новую нагрузку, положили сеть. Снять дампы или включить детальный мониторинг было нереально. А причину, без инструмента и исходных данных, искали, как вы понимаете, теоретически, в последних-предпоследних-предпредпоследних изменениях. Судорожные откаты к результату не приводили, управлять пользователям мы в тот момент не умели. А про крыж в настройках никто не подумал, потому что дата файла с этими настройками из репозитория (феншуй епрст!) оказалась, как можно догадаться, 2-х месячной давности.
Как DBA отвечу:
И разработка и ревью изменений БД - было. И на деве, тесте, предпроде и, частично на проде, были настроены мониторинги - кривые запросы к БД отлавливались автоматом по целому сету условий. Но на экранах радаров эту мелочь не заметили, от пары юзверей пусть даже несколько тысяч запросов, из кеша в пару тестовых записей, которые относительно нескольких сотен транзакций в секунду, не попали в top-100 ни по одному показателю.
Графики нагрузки на продуктивные БД имели историю, анализ, с указанием причин изменений ключевых показателей, объяснения динамики и "красные линии", с историчностью в несколько лет и разбирались на еженедельной основе вместе с разрабами. И с точки зрения написанного кода, и бизнес-показателей, внедрения новых фич и тп. Не говоря уже про даш-борды и алерты для группы онлайн-мониторинга 24х7.
"Можно придумать защиту от дурака, но только неизобретательного" ИТ-шная мудрость
Конечно, нет. Неужели можно предположить, что перед тем, как добраться до расширенных настроек биоса, старый админ не проверил все порты, режимы/настройки системы, не перелопатил реестр и тп :) Дошел до инженеров вендора - увы.
А про виртуальные карты месье не слышал и копирование номера из банковского приложения? И чем плохи менеджеры паролей, которые не хранят данные неизвестно где "в облаке" и доступа в сеть не имеют?
Боль! Года 3-4 назад победил, тоже был тот еще квест, через расширенные настройки биоса и правкой реестра.
Но осталась одна нерешенная - USB порт не отключается никак, кроме как при shutdown. А на это было завязан сетап с отключением питания периферии (подставки/монитора и тп). Максимум достигнутого, порт отключается при отсутствии внешнего питания. И это "by design".
Институт Проблем Управления (ИПУ) был одним из тех, кто считал зарплату для других, и гуляла байка. Привозили списки особые люди с чемоданчиками на браслетах, и, как правило, накануне 5-го и 20-го, сразу все. Множество теток-машинисток забивало все это на УПД, потом программеры переносили на ЭВМ. Один из сотрудников лабы подготовки данных попросил одних таких привести в следующий раз не распечатку, которую сразу было видно, а записать на носитель - хотя бы перфорленту, если магнитных лент нет. И в следующий раз привезли. Сколько потребовалось солдат, чтобы переписать текст на перфоленту никто не знает, а того, кто это увидел, потом долго отпаивали спиртом.
Шпаргалка вещь хорошая, но многим из поколения ЕГЭ нужны готовые примеры. Могу порекомендовать по SQL книжку с хорошими примерами, проверенную веками :), http://db2-sql-cookbook.org/, особенности синтаксиса db2 можно спокойно пропустить.
Нам не нужны умные, нам нужны исполнительные. Из эпохи 70-х, откуда все нынешнее властное берет методички...
"Стремление рационализировать то, что не нужно рационализировать" - это прям моя боль, оптимизировать любое действие... И да, проще сделать самому.
Убили OS2 маркетинг IBM и умный Гейтс.
Многие упрекали полуось за интерфейс, а это у IBM прям фетиш, но чего до сих пор мне не хватает:
возможность подвигать неактивное окно, не закрывая активное
событийной модели на фолдеры - это было шедеврально, кидает бух файлик мышкой в папочку и опа, магия. И это было до 95 :)
А какой был Visual REXX и Watcom'овские продукты... Ну а просто REXX до сих пор со мной, как и FileCommander.
"если полетит полуось нам все крышка" (с) из SU.OS2
А как же звук хэндшейка, обрыв на последних байтах долгожданного пакета с эхой, поинтовка и пиво с сисопом?! А BBS модели чебурашка, которая могла жить в любой телефонной будке? Скупая слеза и олдскулы свело.
2:5020/1.21, таскал эхи еще на 1200/bizнифига.
Начинать надо с того, что сам отчет-то правильно сформировали или просто табличку нашли? С реальными выплатами сравнили хотя бы? Если там 115+ деньги получает - агента Малдера послали?
Ну есть поле в БД жив/нет и что? Вон наш ПФР пытается заставить определить это состояние банки, чтобы они мониторили активность клиента, получающего соцвыплаты. Что они потом с этим делают - хз.
А мне интересно, откуда взялся график? Его собирали "на всякую случку" или был повод ранее? Если первое, то нужно просматривать результаты мониторинга и отлавливать аномалии по всем собираемым показателям, при чем и на тестовых средах, что наиболее правильно, и при раскатке на фокусных группах особенно. А если второе, то нужно еще и сделать оргвыводы.
а можно нарисовать сову у которой есть и задние и передние лапы? Очень интересно, как выглядит
сфисовинск(?).На одной работе нужно работать 8 часов в день, а на другой - головой.
много лет висит как фон десктопа/зума
Страшный сон для DBA.
Но если данный подход под микросервис, под которым БД на 3 таблицы в сотню строк - да пофиг, там и sql нафиг. Но "когда у тебя в руках молоток, весь мир - гвозди".
Для промышленного применения, когда у тебя БД нагрузкой, каждый запрос умножается на число его вызовов. Исправить ошибки проектирования сложнее чем ошибку в днк проектировщика. На заре появления реляционных БД инженеры думали головой. Например, static(embedded) sql и никаких инъекций, и сервер не занимается компиляциями однотипных запросов, стоимость которых на порядок выше цены их исполнения, и никаких вопросов "кто написал этот скуль?! Сервер лег!", и безопам счастье, никаких юзеров, одни спузы.
Автогенераторы кода для БД давно существуют для компенсации скиллов разработчиков. Прототипировать годиться. Но когда такой продукт идет в бой, наступает прозрение. Но переписывать уже работающий код...
Если бы еще инженеры в далеком 2000 не сдались с SQL SP, то не было бы антипаттерна про бизнес-логику в БД... :)
Все банки подключены к ГИС ГМП. Это коммуналка, штрафы, судебные и тп. Получить из госсистемы начисления можно по ИНН, который банк знает. И банк обязан проверить наличие и статус в ГИС ГМП, если в платежке есть поле УИД (22, и, кто бы мог подумать, оно же теперь для ЭДО с ФНС после перехода на ЕНС, чтоб ИТ не скучали) - чтобы избежать ситуации, когда два банка (авто)платеж сделают по одному начислению.
Так почему бы не помочь клиенту комфортно потратить деньги на неприятные вещи типа штрафа, предзаполнив за него правильно все поля?
И 152-ФЗ это не про госорганы.
Любая нештатная ситуация сначала возникает первый раз. Например, скорость мониторинга могла не успеть за метрикой или создание такой ситуации самой системой мониторинга. Но больше вероятность человеческого фактора, в том числе из лучших побуждений, например при невозможности воспроизвести ошибку на тесте приходиться рисковать на бою - сам так делал :)
Япония - работает, сильно упрощая процесс перевода. Потому что перекинуть деньги иным способом - это обязательный поход в Банк по предварительной записи с доказательными бумажками и 2-3 недели на сам перевод, у Примсоц чуть быстрее в пару банков.
Идея класс! Но, как пользователь со стажем, задам вопрос - колебания монитора на столь длинном рычаге при движении как-то решены? При долгом сидении, даже в сверхудобном положении,что-то затекает и организм начинает это компенсировать - мы меняем положение, трясем ногой и пр. Просто при работе с клавиатурой есть колебания весьма монолитного стола. Я был вынужден был заменить кронштейн для монитора, который крепился к столу, на настенный вариант. В данной конструкции, как я вижу, колебания будут напрямую передаваться на монитор. Какой был кошмар в свое время из-за колебания решетки на тринитронах...
" в команде нет DBA"
Зацепило.
Как погруженный в тему - не всегда можно предвидеть. Имея весьма нескромный опыт в кровавом энтерпрайзе и построив эшелонированную оборону от разработки до деплоя на прод, несколько раз ловил epic fail.
В качестве примера - была задача по ограничению доступной инфы на экране признаку VIP. VIP'ов было пара сотен, что на фоне миллионов клиентов даже в пределы погрешности не укладывалось. Задачку примитивная, скинули джуну, по феншую фичу даже протестировали на паре офисов и забыли до отмашки заказчиком. Через пару месяцев вместе с глобальным обновлением включили в релиз - как крыжик в настройках...
Джун, ему простительно, реализовал прекрасно: на каждый (ты вдруг VIP'ом стал внезапно) got/lost focus элемента формы проверка через select * from vip, дальше поиск по массиву уже на клиенте...
В форме, центральной, было несколько десятков закладок, пара сотен статических и, в зависимости от, еще минимум сотня динамических элементов. А в момент открытия формы, как мы потом узнали, каждый (!) элемент генерил эти 2 события. И в понедельник утром > 5 тыс. ничего не подозревающих пользователей пришли на работу. И не могли открыть форму, приложение "висело", они его срубали и открывали заново. Восточные регионы успели, а следующие часовые пояса уже нет, что внесло свои коррективы в понимание проблемы. Мы докидывали сервера приложений, которые принимались переваривать все новые сессии пользователей, а старые никуда не девались, пока не дорабатывали до конца или мы не перегружали сервак. Между БД и серверами приложений гнался немеренный траффик. К БД было подключено несколько десятков и других приложений, и там тоже началась деградация.
Тем, кто не очень в теме БД, простой select из базы в таком виде грубо: declare stmt/open cursor/fetch 200+ rows/close cursor, каждое действие это несколько пакетов, каждый фетч страница в 4Кб, умноженное на число строк в таблице - 200+ и умноженное на 2*300 раз за контрол на форме на каждого пользователя=5000 и каждую зависшую сессию - умножить еще на 2. И все это в единицу времени. "Ватага зайцев мочит льва."
Мы ddos-или собственную инфру. И самое главное, не понимали причину, поднимали новые сервера => создавали все новую нагрузку, положили сеть. Снять дампы или включить детальный мониторинг было нереально. А причину, без инструмента и исходных данных, искали, как вы понимаете, теоретически, в последних-предпоследних-предпредпоследних изменениях. Судорожные откаты к результату не приводили, управлять пользователям мы в тот момент не умели. А про крыж в настройках никто не подумал, потому что дата файла с этими настройками из репозитория (феншуй епрст!) оказалась, как можно догадаться, 2-х месячной давности.
Как DBA отвечу:
И разработка и ревью изменений БД - было. И на деве, тесте, предпроде и, частично на проде, были настроены мониторинги - кривые запросы к БД отлавливались автоматом по целому сету условий. Но на экранах радаров эту мелочь не заметили, от пары юзверей пусть даже несколько тысяч запросов, из кеша в пару тестовых записей, которые относительно нескольких сотен транзакций в секунду, не попали в top-100 ни по одному показателю.
Графики нагрузки на продуктивные БД имели историю, анализ, с указанием причин изменений ключевых показателей, объяснения динамики и "красные линии", с историчностью в несколько лет и разбирались на еженедельной основе вместе с разрабами. И с точки зрения написанного кода, и бизнес-показателей, внедрения новых фич и тп. Не говоря уже про даш-борды и алерты для группы онлайн-мониторинга 24х7.
"Можно придумать защиту от дурака, но только неизобретательного" ИТ-шная мудрость
Конечно, нет. Неужели можно предположить, что перед тем, как добраться до расширенных настроек биоса, старый админ не проверил все порты, режимы/настройки системы, не перелопатил реестр и тп :) Дошел до инженеров вендора - увы.
А про виртуальные карты месье не слышал и копирование номера из банковского приложения? И чем плохи менеджеры паролей, которые не хранят данные неизвестно где "в облаке" и доступа в сеть не имеют?
Боль! Года 3-4 назад победил, тоже был тот еще квест, через расширенные настройки биоса и правкой реестра.
Но осталась одна нерешенная - USB порт не отключается никак, кроме как при shutdown. А на это было завязан сетап с отключением питания периферии (подставки/монитора и тп). Максимум достигнутого, порт отключается при отсутствии внешнего питания. И это "by design".
Институт Проблем Управления (ИПУ) был одним из тех, кто считал зарплату для других, и гуляла байка. Привозили списки особые люди с чемоданчиками на браслетах, и, как правило, накануне 5-го и 20-го, сразу все. Множество теток-машинисток забивало все это на УПД, потом программеры переносили на ЭВМ. Один из сотрудников лабы подготовки данных попросил одних таких привести в следующий раз не распечатку, которую сразу было видно, а записать на носитель - хотя бы перфорленту, если магнитных лент нет. И в следующий раз привезли. Сколько потребовалось солдат, чтобы переписать текст на перфоленту никто не знает, а того, кто это увидел, потом долго отпаивали спиртом.
Шпаргалка вещь хорошая, но многим из поколения ЕГЭ нужны готовые примеры. Могу порекомендовать по SQL книжку с хорошими примерами, проверенную веками :), http://db2-sql-cookbook.org/, особенности синтаксиса db2 можно спокойно пропустить.