Что-то при перечислении API забыли Zabbix. А у него тоже есть. Оченно полезная штука, когда надо сверить настройки хостов и макросов заббикса и данные из NetBox, например (у которого тоже API).
Мне вот всегда интересно то, что происходит на границах Agile-команды, а не внутри. Допустим, владелец продукта говорит "мне нужно, чтобы фича Х отрабатывала на 8 секунд быстрее, тогда за год на уменьшении тормозов контора сэкономит Y*100000 рублей". Члены команды анализируют свой продукт и получается, что силами разработчиков (оптимизацией кода) можно ускорить на 2 секунды, а для реализации оставшихся 6 нужно перейти на Full-flash СХД. А дальше? Отдел закупок тоже работает по Agile и быстро покупает? Или работает по-старинке и тянет резину (конкурсы там какие, сбор КП и т.д.)? Или как?
А как именно "добывалась" информация о длине абонентской линии? Сейчас понятно, можно попросить абонента отрубить оборудование и загнать порт в режим диагностики. А вот в "начале 2000-х" я что-то такой возможности не припомню. Или измеряли флюком при подключении и записывали в базу/description на самом порту?
Введение массовых выплат потребует видоизменения как финансовой, так и налоговой систем государств, где решили реализовать безусловный базовый доход. Возможно, придется даже урезать другие статьи расходов бюджета, чтобы удовлетворить новую.
Это же вроде подаётся апологетами ББД как плюс, а не минус? В том контексте, что убрав множество сложных схем различных социальных выплат можно хорошо сэкономить на ордах чиновников, обслуживающих эти схемы.
Если будете их тестировать, не забывайте включать нужные для MPLS протоколы и на Loopback-интерфейсах. А то про это в инструкции может не быть указано.
прямого обмена маршрутами каждого с каждым тоже быть при таком количестве узлов не может (нафигачить-то в конфигурацию скриптами/анзиблем можно, только железки придётся уж очень недешёвые покупать)
Мало того, что цена выше. Насколько я понимаю, проблема того, что гелий просачивается через материал обшивки баллонов весьма хорошо, до сих пор не решена.
Тут надо не только переключение языков. Тут надо ещё и поисковые предпочтения иметь возможность на .com переключить. В статье про то, как заставить браузер работать только и исключительно с .com-версией народ жаловался, что на .ru-версии поиск ставит в приоритет наших локальных перекупщиков (я такого не видел, но я на русском запросы в поиске не делаю).
Три, наверное? При двух мы можем узнать, что результат вычислений неправильный (и то вероятность одинаковой ошибки есть). А при трёх можно положиться на два совпадающих результата, опять же понимая, что минимальная надёжность такой схемы обусловлена появлением двух одинаковых ошибок в двух блоках.
Если Вы делаете автоматическое определение поездки, сделайте взаимодействие с Bluetooth LE маячком, который можно закинуть в карман двери водителя. Есть маячок - едем водителем. Нет маячка - пассажиром. Заодно можно машины по маячкам различать, если их несколько. Что будет с "опасным ночным периодом", если водитель уехал за три часовых пояса на запад или восток, а часы на смартфоне не перевелись?
Лучше, когда "винтик" делает свою работу так, чтобы следующие по техпроцессу "винтики" тоже могли делать свою работу хорошо. И если нужно затратить на это некоторое время, в том числе и время более высокооплачиваемых "винтиков", то это очень часто может оказаться экономически оправдано.
Не просто "отсутствие обратной связи", а "отсутствие отрицательной обратной связи". Если нужна стабильная и предсказуемо работающая система, в первую очередь нужна отрицательная обратная связь.
Так подтверждает целый психиатр. А он, вроде как, повыше в иерархии будет, чем психолог. А сейчас к психиатру и наркологу добавили ещё и экспресс-тест на наркотики.
Увы, человек очень сильно заточен под "набивание фрагов", эволюция подсобила. Даже ограничение доступа к знаниям, как сделать вундерфавлю, не сильно поможет, ведь можно долго прокачивать чисто физическую силу и умение убивать голыми руками в рамках вполне милых и полезных для организма физкультурных упражнений.
Тут есть нюанс. Магазин не может по "зелёнке" продать патроны. Только по РОХа. А если покупать оружие у частного лица, то оно может тебе подарить ненужные ему больше патроны к этому оружию. Продать формально не может, а вот подарить запросто. Так что Ваш сценарий очень даже возможен.
Что-то при перечислении API забыли Zabbix. А у него тоже есть.
Оченно полезная штука, когда надо сверить настройки хостов и макросов заббикса и данные из NetBox, например (у которого тоже API).
Для ленивых: RAIN (redundant/reliable array of inexpensive/independent nodes)
Мне вот всегда интересно то, что происходит на границах Agile-команды, а не внутри. Допустим, владелец продукта говорит "мне нужно, чтобы фича Х отрабатывала на 8 секунд быстрее, тогда за год на уменьшении тормозов контора сэкономит Y*100000 рублей".
Члены команды анализируют свой продукт и получается, что силами разработчиков (оптимизацией кода) можно ускорить на 2 секунды, а для реализации оставшихся 6 нужно перейти на Full-flash СХД.
А дальше? Отдел закупок тоже работает по Agile и быстро покупает? Или работает по-старинке и тянет резину (конкурсы там какие, сбор КП и т.д.)? Или как?
А как именно "добывалась" информация о длине абонентской линии? Сейчас понятно, можно попросить абонента отрубить оборудование и загнать порт в режим диагностики. А вот в "начале 2000-х" я что-то такой возможности не припомню.
Или измеряли флюком при подключении и записывали в базу/description на самом порту?
Что-то сомнительно, чтобы они специально для этого ружья стандартный для MP-155 патронник уменьшили. Это же не сверхбюджетник...
Это же вроде подаётся апологетами ББД как плюс, а не минус? В том контексте, что убрав множество сложных схем различных социальных выплат можно хорошо сэкономить на ордах чиновников, обслуживающих эти схемы.
А "проблема танков" - это опечатка? Или что-то слэнговое?
И ещё, какая часть из 50 Гбит/с на мелланоксе (два порта по 25) использовалась для vSAN?
Если будете их тестировать, не забывайте включать нужные для MPLS протоколы и на Loopback-интерфейсах. А то про это в инструкции может не быть указано.
А какие-нибудь железки с 10/40G интерфейсами и поддержкой MPLS Вы тестировали? Или в Вашем случае MPLS не актуален?
full mesh? Что-то не вяжется:
физической связи каждого с каждым точно нет
прямого обмена маршрутами каждого с каждым тоже быть при таком количестве узлов не может (нафигачить-то в конфигурацию скриптами/анзиблем можно, только железки придётся уж очень недешёвые покупать)
Если Вы делаете автоматическое определение поездки, сделайте взаимодействие с Bluetooth LE маячком, который можно закинуть в карман двери водителя. Есть маячок - едем водителем. Нет маячка - пассажиром. Заодно можно машины по маячкам различать, если их несколько.
Что будет с "опасным ночным периодом", если водитель уехал за три часовых пояса на запад или восток, а часы на смартфоне не перевелись?
Лучше, когда "винтик" делает свою работу так, чтобы следующие по техпроцессу "винтики" тоже могли делать свою работу хорошо. И если нужно затратить на это некоторое время, в том числе и время более высокооплачиваемых "винтиков", то это очень часто может оказаться экономически оправдано.
Не просто "отсутствие обратной связи", а "отсутствие отрицательной обратной связи". Если нужна стабильная и предсказуемо работающая система, в первую очередь нужна отрицательная обратная связь.
Так подтверждает целый психиатр. А он, вроде как, повыше в иерархии будет, чем психолог. А сейчас к психиатру и наркологу добавили ещё и экспресс-тест на наркотики.
Увы, человек очень сильно заточен под "набивание фрагов", эволюция подсобила. Даже ограничение доступа к знаниям, как сделать вундерфавлю, не сильно поможет, ведь можно долго прокачивать чисто физическую силу и умение убивать голыми руками в рамках вполне милых и полезных для организма физкультурных упражнений.
Тут есть нюанс. Магазин не может по "зелёнке" продать патроны. Только по РОХа. А если покупать оружие у частного лица, то оно может тебе подарить ненужные ему больше патроны к этому оружию. Продать формально не может, а вот подарить запросто. Так что Ваш сценарий очень даже возможен.