Не скажу конкретно про автора, но в каком-нибудь немаленьком интеграторе вполне может быть департамент развития корпоративных продаж, и там может быть архитектор, основная функция которого проектировать за заказ ИТ архитектуры, безо всяких продаж.
Если архитектор не может доходчиво и понятно объяснить сложное, не важно кому, СД или разрабам/админам, то его карьера будет, возможно, яркой, но не долгой.
Представьте строительного архитектора, которые заикаясь рассказывает про свою задумку строительства условного моста или высотки.
Обычно все рабочие места подключаются к бесперебойному снабжению (п.3, 4 из классификации чуть выше)
Ну как обычно, тем кому не нужны простои в работе людей.
Под рабочим местом понимается обычно комп.
Озвучена, скорее всего, часть истории. Предполагаю, звонок из региона был последней каплей.
Общий вывод, формальный подход губит бизнес. Для ИТ это звучит ужасно, т.к. ИТ предполагает строгую формализацию везде и во всем. Но жизнь несколько сложнее строгих систем.
Если на той стороне было больше 3-х человек, то нормальный срок.
Это беда всех больших компаний. Крайне сложно собрать группу людей, принимающих решения, в одном месте в один час по не самым приоритетным задачам.
А насчет второй производной… Это просто тест на технический бэкграунд.
БД — это Data. Сервер приложений — это Application. Браузер — это Presentation.
У каждого слоя свои сложности с разработкой и тестированием.
Очевидно, переносимость подходов к разработке и тестированию в этих разных слоях хоть и коррелирует, но слабо.
Это не отменяет полезности юнит-тестов в слое Application.
И это не отменяет полезности интеграционных тестов, когда все слои собраны вместе.
И это не отменяет все прочие подходы к верификации качества, каждого слоя в отдельности, так и разного их сочетания.
Битва меча и щита.
Прокси научились подменять сертификаты.
Браузеры научились проверять сертификаты (HPKP, привет).
Ждем ответа от щита (прокси).
Наверно, под давлением, производители браузеров HPKP сделают отключаемым, хотя бы в корпоративной среде. Либо прокси разрешат подключаться только через те браузеры, в которых HPKP отключен.
И с этой стороны тоже непонятно.
Поколоночное хранение обычно используют для DWH, а DWH обычно предполагает, что объем таков, что ни в какую память не поместиться. Соответственно, остается поколоночное хранение для обычных баз. С дисками поколоночное хранение для обычных баз не используют из-за дороговизны модификации данных. С памятью наверно это перестает быть узким местом. Но это предположение.
Если таблица все целиком лежит в памяти, почему на индексы места не хватает? Понятно, что это дополнительное место. Но обычный кейс с индексами — они меньше таблиц.
И если мы часть храним в памяти, часть на диске, очевидно преимущества от использования памяти нивелируются. И вместо прироста производительности на порядки, получаем на проценты.
Представьте,
— БД в надцать ТБ
— несколько тысяч таблиц
— несколько десятков тысяч пакетов
— несколько десятков людей, которые каждый день правят базу, пару раз в неделю выкатывают релизы в прод.
Простое копирование базы с прода в дев, зачистка персональных данных и прочей чувствительной информации традиционными инструментами БД занимает несколько суток. Чистить данные? В целом рационально. Но помните про количество таблиц и пакетов? Конечно есть партиции, отключение констреинтов и прочие хитрости, но и они не спасают от длительности операций. Получаем срок от недели и больше.
Это только технические сложности. А есть и просто бизнесовые.
Продукты не статичны. Сегодня контора продает продукт А с одними свойствами, завтра тот же продукт А с другими свойствами, послезавтра с третьими и т.д. В итоге, не имея возможности гонять операции со всех существующих сущностях, получаем, у одного клиента все работает как задумано, у второго проблемы.
А можете поделиться реальным кейсом с цифрами? Размер БД, скорость изменений (как много изменений в БД), за сколько скидывается снимок на диск, сколько при этом накапливается изменений в диффах (соответственно сколько нужно дополнительной памяти), скорость диска, каков прирост вычислительной нагрузки во время сброса снимка на диск и т.д.
Объективно подходя к вопросу, телефонные технологии по определению не являются секурными. Их не создавали для этого.
Также можно, например, слать ПИН по электронной почте. В частном случае, тоже можно обеспечить его безопасность со стороны инфраструктуры. Будет ли такой подход в целом правильным?
И сейчас же мы не рассматриваем особенности работы конкретной компании. Мы говорим про технологии. Про их сильные и слабые стороны. Слать ПИН по SMS — не самое лучшее решение с точки зрения безопасности. С точки зрения удобства конечного пользователя — очень может быть, что удобно.
зы
сейчас почти все телефоны обладают функционалом загрузки содержимого телефона в облако.
т.е. пин твоей карты уже лежит где-то в интернете… узас-узас
Из статьи осталось неясным, как связаны между собой некие приватные ключи и SMS на телефонах.
То что карточные процессинги не хранят пин, понятно.
То что в карточном процессинге где-то лежат приватные ключи, которые участвуют в авторизации пинов, тоже понятно.
Но причем здесь SMS на телефонах?
SMS-ки ходят по обычным условным sms-сным протоколам. Приватность обеспечивается только на уровне инфраструктуры. Соответственно доступ к sms-кам имеют все те, кто имеет доступ к инфраструктуре. Т.е. в связке Банк-Оператор это несколько десятков или сотен человек. Понятно, что есть сертификация PCI DSS. Но те, кто надеется, что наличии сертификации PCI DSS автоматически гарантирует недоступность пинов — они несколько самонадеянны.
В целом, тенденция использования SMS-ок вместо бумажных конвертов удручает. С конвертами хотя бы понятно, кто физически имеет доступ в помещение с принтером.
Вы рассуждаете, как типичный ИТ-шник, что нормально.
К счастью, или к сожалению, за операционные риски отвечает чувак, как правило, далекий от ИТ. Этот умный чувак пишет правила. Задача всех прочих, в том числе ИТ-шников, эти правила соблюдать. Написали: все ПО должно быть с поддержкой, это значит все (все) ПО должны быть с поддержкой.
Авторы PVS пробуют еще один канал продажи. Больше каналов хороших и полезных!
Зачастую вообще боятся бесплатного ПО (да, именно бесплатного, безо всяких ограничений) из соображений «а вот как бы чего не вышло», типа у них на душе неспокойно, пока за него денег кому-то не занесли
Все проще. У больших контор там (там), как правило, процессы зрелые, деньги посчитаны, и есть такая штука — операционные риски. И один из рисков — ПО, которое развернуто без наличия поддержки. Это риск. Вдруг в один прекрасный день обнаружится баг, уязвимость, и прочие радости мира ПО. И остановится какой-то важный процесс, компания будет терять реальные деньги. В результате, появляется требование — любое ПО должно иметь поддержку. Очевидно, у бесплатного, поддержки скорее всего не будет. И второе требование, поставщик поддержки — не компания-однодневка.
Кстати, в связи с этим и процветают конторы типа Red Hat и т.д.
Проблема в том, что конвертация в ряде случаев выполняется несколько сложнее, чем указано у вас в первом абзаце (там и курс может браться не на дату покупки, и конвертаций может быть больше чем одна, и списание не всегда выполняется в одну операцию). И вот тут возникает дилемма, описывать все варианты человеческим языком? или сослаться на договор и правила взаиморасчетов?
Представьте строительного архитектора, которые заикаясь рассказывает про свою задумку строительства условного моста или высотки.
Ну как обычно, тем кому не нужны простои в работе людей.
Под рабочим местом понимается обычно комп.
Общий вывод, формальный подход губит бизнес. Для ИТ это звучит ужасно, т.к. ИТ предполагает строгую формализацию везде и во всем. Но жизнь несколько сложнее строгих систем.
Это беда всех больших компаний. Крайне сложно собрать группу людей, принимающих решения, в одном месте в один час по не самым приоритетным задачам.
А насчет второй производной… Это просто тест на технический бэкграунд.
У каждого слоя свои сложности с разработкой и тестированием.
Очевидно, переносимость подходов к разработке и тестированию в этих разных слоях хоть и коррелирует, но слабо.
Это не отменяет полезности юнит-тестов в слое Application.
И это не отменяет полезности интеграционных тестов, когда все слои собраны вместе.
И это не отменяет все прочие подходы к верификации качества, каждого слоя в отдельности, так и разного их сочетания.
Прокси научились подменять сертификаты.
Браузеры научились проверять сертификаты (HPKP, привет).
Ждем ответа от щита (прокси).
Наверно, под давлением, производители браузеров HPKP сделают отключаемым, хотя бы в корпоративной среде. Либо прокси разрешат подключаться только через те браузеры, в которых HPKP отключен.
И да, шаровой.
Поколоночное хранение обычно используют для DWH, а DWH обычно предполагает, что объем таков, что ни в какую память не поместиться. Соответственно, остается поколоночное хранение для обычных баз. С дисками поколоночное хранение для обычных баз не используют из-за дороговизны модификации данных. С памятью наверно это перестает быть узким местом. Но это предположение.
Если таблица все целиком лежит в памяти, почему на индексы места не хватает? Понятно, что это дополнительное место. Но обычный кейс с индексами — они меньше таблиц.
И если мы часть храним в памяти, часть на диске, очевидно преимущества от использования памяти нивелируются. И вместо прироста производительности на порядки, получаем на проценты.
— БД в надцать ТБ
— несколько тысяч таблиц
— несколько десятков тысяч пакетов
— несколько десятков людей, которые каждый день правят базу, пару раз в неделю выкатывают релизы в прод.
Простое копирование базы с прода в дев, зачистка персональных данных и прочей чувствительной информации традиционными инструментами БД занимает несколько суток. Чистить данные? В целом рационально. Но помните про количество таблиц и пакетов? Конечно есть партиции, отключение констреинтов и прочие хитрости, но и они не спасают от длительности операций. Получаем срок от недели и больше.
Это только технические сложности. А есть и просто бизнесовые.
Продукты не статичны. Сегодня контора продает продукт А с одними свойствами, завтра тот же продукт А с другими свойствами, послезавтра с третьими и т.д. В итоге, не имея возможности гонять операции со всех существующих сущностях, получаем, у одного клиента все работает как задумано, у второго проблемы.
Объективно подходя к вопросу, телефонные технологии по определению не являются секурными. Их не создавали для этого.
Также можно, например, слать ПИН по электронной почте. В частном случае, тоже можно обеспечить его безопасность со стороны инфраструктуры. Будет ли такой подход в целом правильным?
И сейчас же мы не рассматриваем особенности работы конкретной компании. Мы говорим про технологии. Про их сильные и слабые стороны. Слать ПИН по SMS — не самое лучшее решение с точки зрения безопасности. С точки зрения удобства конечного пользователя — очень может быть, что удобно.
зы
сейчас почти все телефоны обладают функционалом загрузки содержимого телефона в облако.
т.е. пин твоей карты уже лежит где-то в интернете… узас-узас
В чем отличие? Delphix — полностью софтовое решение. Отсюда все плюсы и минусы.
Что лучше? Это все равно что выяснять, что лучше, какой-нибудь железный маршрутизатор, или sdn-решение?
То что карточные процессинги не хранят пин, понятно.
То что в карточном процессинге где-то лежат приватные ключи, которые участвуют в авторизации пинов, тоже понятно.
Но причем здесь SMS на телефонах?
SMS-ки ходят по обычным условным sms-сным протоколам. Приватность обеспечивается только на уровне инфраструктуры. Соответственно доступ к sms-кам имеют все те, кто имеет доступ к инфраструктуре. Т.е. в связке Банк-Оператор это несколько десятков или сотен человек. Понятно, что есть сертификация PCI DSS. Но те, кто надеется, что наличии сертификации PCI DSS автоматически гарантирует недоступность пинов — они несколько самонадеянны.
В целом, тенденция использования SMS-ок вместо бумажных конвертов удручает. С конвертами хотя бы понятно, кто физически имеет доступ в помещение с принтером.
К счастью, или к сожалению, за операционные риски отвечает чувак, как правило, далекий от ИТ. Этот умный чувак пишет правила. Задача всех прочих, в том числе ИТ-шников, эти правила соблюдать. Написали: все ПО должно быть с поддержкой, это значит все (все) ПО должны быть с поддержкой.
Авторы PVS пробуют еще один канал продажи. Больше каналов хороших и полезных!
Все проще. У больших контор там (там), как правило, процессы зрелые, деньги посчитаны, и есть такая штука — операционные риски. И один из рисков — ПО, которое развернуто без наличия поддержки. Это риск. Вдруг в один прекрасный день обнаружится баг, уязвимость, и прочие радости мира ПО. И остановится какой-то важный процесс, компания будет терять реальные деньги. В результате, появляется требование — любое ПО должно иметь поддержку. Очевидно, у бесплатного, поддержки скорее всего не будет. И второе требование, поставщик поддержки — не компания-однодневка.
Кстати, в связи с этим и процветают конторы типа Red Hat и т.д.