У нас на один сервер приложений генерировалось где то 6 ГБ сжатых инфо и выше текстовых логов в сутки, примерно такой же объём уходил в кафку. В kibana был доступ только к инфологам, и для двух дц по несколько десятков основных серверов достаточно тормозной, на какой инфрастрвктуре это работало было тайной. Да и толку от инфо логов кроме как для статистики особо не было, ну разве что локализовать инцидент. Дебаг в кафку не пускали, поэтому приходилось всё равно брать 1-3 сжатых часовых лога и изучать в less. К счастью логи были внутренние
У меня была такая же проблема, когда учился - не чувствовал хода стопы на сцеплении и газе. Помогли 2 упражнения - дома резинка, которой тянул носок каждой ступни и медленно в противофазе нажимал и отпускал воображаемые педали. Второе -когда гулял с дочкой в песочнице, делал такую горку и мял её ступнями, имитируя нажатия.
Интересны абсолютные цифры объёма и скорости достигнутого логгирования. Допустим, на один сервер 12 ГБ в час, 50 серверов в одном датацентре. Просто общался с kibana, и не очень она была полезна именно для изучения логов, всё равно приходилось идти к тексту
Хорошая статья и проект, да и к Технониколь по опыту строительства дома отношение норм. При прочтении комментов возникли мысли - да, некоторые вещи типа выбор комплектующих, протоколов и стеков, можно бы было сделать эффективней, но как? Технологии тензоизмерений не очень связаны с мех технологиями объединения датчиков, а те не очень заточены на что то типа msp430 vs esp32. Зато оптимизировать работающее изделие уже можно в каждой отдельной сфере, в том числе после публикации проекта на хабр) ОпенПроджект?)
Мой бывший шеф, среди прочих менеджеров, прособеседовал нового сто, тот прошёл исп. срок и под свою програму развития получил бюджет. Сразу же он заявил что продукт отстой, мы его больше делать не будем и команда будет его переписывать. Нанял новых людей, начался какой то треш с падениями продакшена, освоением новых стеков и подготовкой демо на их основе. Мой шеф ушёл, я с коллегой перешли в багфикс.
В итого: Через 2 года у сто отобрали половину ресурсов. Переход на новую платформу отменили. Мой шеф вернулся) Бюджет ушёл в игры и политику. Единственное достижение -ipo и пара хороших вновь пришедших специалистов.
Следующий сто вообще хотел нас всех уволить -плохой продукт, всё переделать, снова демы на лояльных клиентах и тоже мимо. В смысле его ушли, а нововведения допиливали ещё года 2, до беты в продакшене.
Вот точно умение увольнять не определяющее качество успешного руководителя) Ну и к ценностям много вопросов -а как же диверсити, которое тоже в них?)
Так это то, что названо пулинг, а вот второй вариант, насколько я понял, он через проприентарные драйверы, в одном из которых обслуживается ввод вывод через dma
Странно использовать dma для uart 9600, имхо. Fifo есть, прерывание и блокирующее чтение/запись, нагрузки на cpu сравнимы с 0. Да даже пулинг по таймеру несильно загрузит систему, имхо.
Да уж, в академии наук интересно) в 80х был на курсовике в отделе, занимавшемся спектрометрией в субмиллиметровом диапазоне. Они собрали установку на ЛБВ, а чтобы получить стабильный сигнал с широкой перестройкой, сделали 3 кольца фапч - резонатор был перестраиваемый механически моторчиком и червячной передачей, внутри был лазер как стабильный источник, а чтобы получать сигнал рассогласования они медленно "трясли" зеркало резонатора подвесом на пьезокерамических элементов. Уникальное было сооружение -старый железный корпус от чего то лампового, ворох проводов и кабелей и нечто жужжащее на столе, подключенное к чему то вроде двк)
.В госучреждениях ( мед клиника) подобные рекомендации в виде требований ещё зимой рассылали - перед очередной тренировкой. Смысл был чтобы в лабораториях или во время операции какой нибудь аппарат не отключился.
Непонятно, зачем для блокировки иностранных ресурсов, использующихся для информационной войны с нашей страной, надо блокировать внутренние - или изложено некорректно, либо полный дебилизм какой то в этом ведомстве. Следующим тогда что будет -https?
У меня на шлюзе это тоже есть, я так же могу войти локально и даже доступ к настройкам более ээ.. глубокий. Но вот доступ к отоплению мне нужен из города, и пробрасывать куда то с серого айпи этот шлюз такая себе затея, на любителя.
Меня тоже раздражает проприентарщина, закрытость, масса приложений под каждую хрень отдельно,. Купил бойлер, думал он к ha по вайфай подцепится, как у соседа кондиционер - хрен там, шифровано. Пришлось ставить розетку управляемую)
Ну ок, к стиралке доступ вне дома, допустим, не особо нужен, а вот к бойлеру, кондиционеру, каким нибудь котлам? Я про то, что альтернативы приземлять бытовую технику на облачных сервисах нет. Локальный вайфай - ну не знаю, если плюсом, то хорошо, но это менее важно, чем через облако, имхо. Для меня идеально было бы, чтобы вся техника поддерживалась HA по локальным протоколам, но об этом не узнать на 100%, пока не купишь что нить очередное.
Насчёт бесплатной поддержки облачного сервиса - у меня интернет шлюз к контроллеру отопления работает уже 8 лет, периодически что-то там обновляется, меня всё устраивает. Продавался он с пожизненной подпиской впридачу.
В статье и по ссылкам используются термины гранулярность и границы, но рассматривается всё в контексте связанности и прочности. При этом вопросу, почему ИТ система является/стала распределённой внимание не очень уделяется, имхо.
К примеру, есть набор сервисов, которые постоянно ходят в базу за разнородными данными, и иногда достаточно активно их обновляют. Это периодически вызывает блокирование разных таблиц, подвисает логика, и как результат - пользователи UI замечают задержки в приложениях. Или начинают превышаться какие то требования по допустимым таймаутам обработки евентов. С точки зрения архитектуры и данных понятно, что надо рефакторить базу, таблицы, взаимодействия, сервисы, и тогда одна БД превратится в несколько, могут появиться кэши и новые сервера. А можно просто заменить диски условно на SSD, и после 10 кратного ускорения ввода вывода снять проблемы на несколько лет, начав или продолжая плавный рефакторинг архитектуры системы - всё равно надо масштабировать, если бизнес растёт, или ещё что. Это эквивалентно расширению границ области, в которой находятся те же и так же связанные данные БД. То есть, в данном случае, производительность ввода вывода является таким же, если не более важным фактором, как и связанность и прочность. В других задачах производительность вычислений может определять границы для группы как то связанных компонент
Нельзя ли использовать гранулярность как более общую метрику архитектуры? Потому что границы элементов системы связаны с физическими ограничениями, сами зёрна (или какие нить бобы)) и связи между ними определяют связанность и прочность того, что находится в этих границах. Тогда, допустим, будет очевидно, что если несколько бобов не убирается в стопку, надо или перераспределить их между двумя стопками, или пересыпать их в стакан. Если яблоко не убирается в стакан целиком, надо его нарезать на дольки, попутно выкинув всё невкусное, если всё равно не лезет - в два стакана или ещё что нибудь. Очевидно, что нет смысла в эту ёмкость насыпать манку, мечтая что-то там внутри между отдельными кусочками пшеницы организовать по обмену или логике) Но вот с десяток орехов фундука в стакан отлично помещаются - и видно каждый, и стакан почти полностью заполнен
Сначала мы пошли более простым путем — собрали статистику и направили ее на команды, затем с помощью пряника попросили решать инциденты. После этого число инцидентов сократилось, но не особо заметно. Мы решили достать пряник потверже и ввели KPI.
Интересно, а почему команды до этого копили инциденты и нарушали sla? Гнали фичи? В спринтах не выделено время на текучку и баклог? Команды сопровождения недостаточно квалифицированы для расследования и приоритезации инцидентов? Просто такое ощущение, что у вас сначала создали бардак, а потом героической деятельностью и проактивностью релиз менеджмента его пытались устранить, хотя исполнителями как были разработчики, так и остались, только их к концу начали ещё и штрафовать)))
У нас на один сервер приложений генерировалось где то 6 ГБ сжатых инфо и выше текстовых логов в сутки, примерно такой же объём уходил в кафку. В kibana был доступ только к инфологам, и для двух дц по несколько десятков основных серверов достаточно тормозной, на какой инфрастрвктуре это работало было тайной. Да и толку от инфо логов кроме как для статистики особо не было, ну разве что локализовать инцидент. Дебаг в кафку не пускали, поэтому приходилось всё равно брать 1-3 сжатых часовых лога и изучать в less. К счастью логи были внутренние
У меня была такая же проблема, когда учился - не чувствовал хода стопы на сцеплении и газе. Помогли 2 упражнения - дома резинка, которой тянул носок каждой ступни и медленно в противофазе нажимал и отпускал воображаемые педали. Второе -когда гулял с дочкой в песочнице, делал такую горку и мял её ступнями, имитируя нажатия.
Интересны абсолютные цифры объёма и скорости достигнутого логгирования. Допустим, на один сервер 12 ГБ в час, 50 серверов в одном датацентре. Просто общался с kibana, и не очень она была полезна именно для изучения логов, всё равно приходилось идти к тексту
Хорошая статья и проект, да и к Технониколь по опыту строительства дома отношение норм. При прочтении комментов возникли мысли - да, некоторые вещи типа выбор комплектующих, протоколов и стеков, можно бы было сделать эффективней, но как? Технологии тензоизмерений не очень связаны с мех технологиями объединения датчиков, а те не очень заточены на что то типа msp430 vs esp32. Зато оптимизировать работающее изделие уже можно в каждой отдельной сфере, в том числе после публикации проекта на хабр) ОпенПроджект?)
Аа, понял - я просто решил, что xdma это именно dma)
Мой бывший шеф, среди прочих менеджеров, прособеседовал нового сто, тот прошёл исп. срок и под свою програму развития получил бюджет. Сразу же он заявил что продукт отстой, мы его больше делать не будем и команда будет его переписывать. Нанял новых людей, начался какой то треш с падениями продакшена, освоением новых стеков и подготовкой демо на их основе. Мой шеф ушёл, я с коллегой перешли в багфикс.
В итого: Через 2 года у сто отобрали половину ресурсов. Переход на новую платформу отменили. Мой шеф вернулся) Бюджет ушёл в игры и политику. Единственное достижение -ipo и пара хороших вновь пришедших специалистов.
Следующий сто вообще хотел нас всех уволить -плохой продукт, всё переделать, снова демы на лояльных клиентах и тоже мимо. В смысле его ушли, а нововведения допиливали ещё года 2, до беты в продакшене.
Вот точно умение увольнять не определяющее качество успешного руководителя) Ну и к ценностям много вопросов -а как же диверсити, которое тоже в них?)
Так это то, что названо пулинг, а вот второй вариант, насколько я понял, он через проприентарные драйверы, в одном из которых обслуживается ввод вывод через dma
Странно использовать dma для uart 9600, имхо. Fifo есть, прерывание и блокирующее чтение/запись, нагрузки на cpu сравнимы с 0. Да даже пулинг по таймеру несильно загрузит систему, имхо.
Да уж, в академии наук интересно) в 80х был на курсовике в отделе, занимавшемся спектрометрией в субмиллиметровом диапазоне. Они собрали установку на ЛБВ, а чтобы получить стабильный сигнал с широкой перестройкой, сделали 3 кольца фапч - резонатор был перестраиваемый механически моторчиком и червячной передачей, внутри был лазер как стабильный источник, а чтобы получать сигнал рассогласования они медленно "трясли" зеркало резонатора подвесом на пьезокерамических элементов. Уникальное было сооружение -старый железный корпус от чего то лампового, ворох проводов и кабелей и нечто жужжащее на столе, подключенное к чему то вроде двк)
Я "формулировать" учился очень давно. Учитесь вдумчивей)
.В госучреждениях ( мед клиника) подобные рекомендации в виде требований ещё зимой рассылали - перед очередной тренировкой. Смысл был чтобы в лабораториях или во время операции какой нибудь аппарат не отключился.
Непонятно, зачем для блокировки иностранных ресурсов, использующихся для информационной войны с нашей страной, надо блокировать внутренние - или изложено некорректно, либо полный дебилизм какой то в этом ведомстве. Следующим тогда что будет -https?
Мессенджеры используются не только в российском бизнесе
Мессенджеры стоят посередине между почтой и звонком, если бы их не было, в описанных сценариях менеджмент использовал бы телефон.
Проблема не в месенджерах, а в бизнес процессах и отсутствии рпгламентов
У меня на шлюзе это тоже есть, я так же могу войти локально и даже доступ к настройкам более ээ.. глубокий. Но вот доступ к отоплению мне нужен из города, и пробрасывать куда то с серого айпи этот шлюз такая себе затея, на любителя.
Меня тоже раздражает проприентарщина, закрытость, масса приложений под каждую хрень отдельно,. Купил бойлер, думал он к ha по вайфай подцепится, как у соседа кондиционер - хрен там, шифровано. Пришлось ставить розетку управляемую)
Ну ок, к стиралке доступ вне дома, допустим, не особо нужен, а вот к бойлеру, кондиционеру, каким нибудь котлам? Я про то, что альтернативы приземлять бытовую технику на облачных сервисах нет. Локальный вайфай - ну не знаю, если плюсом, то хорошо, но это менее важно, чем через облако, имхо. Для меня идеально было бы, чтобы вся техника поддерживалась HA по локальным протоколам, но об этом не узнать на 100%, пока не купишь что нить очередное.
Насчёт бесплатной поддержки облачного сервиса - у меня интернет шлюз к контроллеру отопления работает уже 8 лет, периодически что-то там обновляется, меня всё устраивает. Продавался он с пожизненной подпиской впридачу.
В статье и по ссылкам используются термины гранулярность и границы, но рассматривается всё в контексте связанности и прочности. При этом вопросу, почему ИТ система является/стала распределённой внимание не очень уделяется, имхо.
К примеру, есть набор сервисов, которые постоянно ходят в базу за разнородными данными, и иногда достаточно активно их обновляют. Это периодически вызывает блокирование разных таблиц, подвисает логика, и как результат - пользователи UI замечают задержки в приложениях. Или начинают превышаться какие то требования по допустимым таймаутам обработки евентов. С точки зрения архитектуры и данных понятно, что надо рефакторить базу, таблицы, взаимодействия, сервисы, и тогда одна БД превратится в несколько, могут появиться кэши и новые сервера. А можно просто заменить диски условно на SSD, и после 10 кратного ускорения ввода вывода снять проблемы на несколько лет, начав или продолжая плавный рефакторинг архитектуры системы - всё равно надо масштабировать, если бизнес растёт, или ещё что. Это эквивалентно расширению границ области, в которой находятся те же и так же связанные данные БД. То есть, в данном случае, производительность ввода вывода является таким же, если не более важным фактором, как и связанность и прочность. В других задачах производительность вычислений может определять границы для группы как то связанных компонент
Нельзя ли использовать гранулярность как более общую метрику архитектуры? Потому что границы элементов системы связаны с физическими ограничениями, сами зёрна (или какие нить бобы)) и связи между ними определяют связанность и прочность того, что находится в этих границах. Тогда, допустим, будет очевидно, что если несколько бобов не убирается в стопку, надо или перераспределить их между двумя стопками, или пересыпать их в стакан. Если яблоко не убирается в стакан целиком, надо его нарезать на дольки, попутно выкинув всё невкусное, если всё равно не лезет - в два стакана или ещё что нибудь. Очевидно, что нет смысла в эту ёмкость насыпать манку, мечтая что-то там внутри между отдельными кусочками пшеницы организовать по обмену или логике) Но вот с десяток орехов фундука в стакан отлично помещаются - и видно каждый, и стакан почти полностью заполнен
Вроде нет аналогов нашим процессорам, или всё же есть?
Интересно, а почему команды до этого копили инциденты и нарушали sla? Гнали фичи? В спринтах не выделено время на текучку и баклог? Команды сопровождения недостаточно квалифицированы для расследования и приоритезации инцидентов? Просто такое ощущение, что у вас сначала создали бардак, а потом героической деятельностью и проактивностью релиз менеджмента его пытались устранить, хотя исполнителями как были разработчики, так и остались, только их к концу начали ещё и штрафовать)))
Я показания в наш местный агрегатор коммуналки не могу передать, какие уж там репозитарии)) Тоже, кстати, через дом.ру
Каждый день 5 км на работу и обратно, пару раз в неделю в магазин километра за 3, в выходные 100 км туда и обратно или ещё 50 туда и обратно плюсом