Почему-то до сих пор ни в одной из статей не увидел комментария о принципиальном различии между прослушкой всего и прослушкой по ордеру. Это же, чёрт возьми, хабр, а не форум телеканала нтв, тут комментирующие позиционируют себя как ИТ сообщество.
Сегодня утром мне пришла в голову замечательная аналогия. Представьте себе Википедию, в которой нет строки поиска. Если хотите прочитать про что либо, вам надо правильно ввести термин в пути к статье. И в статьях нет ссылок, узнать, есть ли статья по какому-либо слову можно опять же вбиванием полного адреса в браузере. Это прослушка по ордеру. Прослушка без ордера — это поисковая строка и ссылки. Появляется возможность использовать мощнейший инструментарий по обработке информации, появившийся за последние 10 лет. Можно не раскрывать уже случившиеся преступления, а предотвращать их! А это уже очень важное отличие, потому что это спасение человеческих жизней.
АНБ достаточно объявить, что они предотвратили пару террактов типа Бостонского, и всё, мнение общественности на их стороне. Потому что для большинства жизнь важнее, чем тайна частной жизни. На втором месте, кстати, скорее всего деньги и семья. Если кому-то privacy важнее — добро пожаловать в Сомали.
Что же касается Сноудена, чем он думал, когда шёл на работу в подрядчика разведывательной организации?
Скорее на получение ключей методом терморектального криптоанализа. Это проще и быстрее, если данные из контейнера понадобятся в качестве доказательств. А не понадобятся — так пусть себе лежат тихонечко.
Вы опять вернулись к концепции «наказать виновных». Взрослые ответственные профессионалы сами готовы сказать «да, вот тут оказалась проблема, мы не знали, что так может случиться, теперь будем знать и учитывать в будущем». Стресс на эту тему (ожидание наказания) у разработчика должен быть только если он знает, что все вокруг уверены, что он плохо работал и всё случилось из-за него. Чтобы не было такого стресса обычно достаточно хорошо работать. Так какое у вас определение стресса?
Про постепенный ввод нагрузки — вы опять забыли, что этап перехода на новую версию позади и откатываться уже некуда. Для зеркалирования внешней нагрузки на тестинг нужно решить нетривиальную, в общем случае, задачу по поддержанию одинакового внутреннего состояния систем (продакшена и тестинга). В простейшем случае — базы данных должны быть синхронны, иначе будут сыпаться ошибки. Для этого вам надо либо посылать ВСЕ запросы в тестинг (и он должен быть размером с продакшен), либо делать срезы, но это тоже сложно. Есть много вариантов, но, опять же, невозможно протестировать всё.
Если у менеджера седеют волосы — это не значит, что он верещит. Нормальный менеджер будет лишь спрашивать, как он может помочь, кого ещё вызвонить-позвать и т.д., то есть способствовать процессу.
Опять вы про виноватых. Прочитайте мой пример из камента выше, про буст и код из официальной документации. Кого назначаете виновным?
ЕМНИП можно же схитрить, если вам не страшна систематическая погрешность. Если координаты базы указать смещёнными относительно истинных координат на некий вектор r, то координаты приёмника будут смещены на тот же самый вектор. Если рассматривать какой нибудь беспилотник, который летает недалеко и получает поправки только от одной базы, то ему будет вполне достаточно. Как вариант — взять карту, ровер, поставить ровер на точку с известными координатами, посчитать ошибку и поправить координаты базы на величину этой ошибки. Геодезической точности, конечно, не получить, но нужна ли она?
Вообще-то я описал первый вариант, а Вы описали второй.
Не вы ли писали про виноватых?
Проблемы тестировщиков программистов не волнуют. Тестировщики не смогли собрать стенд, который эмулирует среду заказчика, значит они и виноваты.
Вы сами сказали, что такие ситуации — это стресс для программистов, а стресс в данных ситуациях будет только тогда, когда нет процедур восстановления и зон ответственности, те когда все пытаются валить на других и все восстановить нужно вчера.
Наверное, стоит тогда определиться, что есть стресс. Если проблему надо быстро найти и решить, работая при этом с живыми данными, максимально сокращая стадию тестирования, и всё это сильно выбивается из нормального ритма работы — это стресс. Примерно как попасть в занос на машине зимой. Есть зоны ответственности, есть процедуры восстановления, но они уже не отработали, это та самая ситуация, что случается редко. Но как только случилась — действовать надо быстро, точно и слаженной командой.
Продолжая аналогию с машиной — у вас уже стоит зимняя резина, и вы вели машину аккуратно. Но покрытие оказалось коварным, ветер неудачно дунул, и машину начало заносить. Хладнокровно нажав на газ (передний привод) и подработав рулём вы выходите из заноса и продолжаете движение. Запаникуете и жмакнете на тормоз — в лучшем случае вас просто развернёт.
Как я уже сказал выше, такие ситуации бывают, но они должны во первых бывать редко, а во вторых, если они случаются, то источниками стресса они быть не должны ибо стресс — это проблема менеджеров и тех, кто пропустил косяк,
Заметьте, вы опять говорите про виноватых. Менеджеры, разработчики и тестировщики работают вместе, их задача — сделать качественный продукт. Если всплыл баг в продакшене, то, скорее всего, виноваты все: одни его сделали, вторые не отловили, третьи просто потому что ответственные за продукт. Вот если один и тот же баг регулярно всплывает — то что-то не так в консерватории. Кстати, совсем не понимаю, почему у QA то стресс должен быть? Ну не смогли найти ошибку, бывает, это нормально. Если косяков в самом процессе тестирования не было — то их даже премии не за что лишать.
а остальные должны спокойно работать на разрешение ситуации.
Спокойно — это как, неспешно попивая кофеёк, а в 19:00 встал и пошёл домой? Фиговенький тогда сервис, прямо скажем. Повторюсь, это ситуация, когда некуда откатываться, чинить надо здесь и сейчас. Или вы говорите про быстро и уверенно? Но темп работы всё равно же будет отличаться от обычного.
Все невозможно, с этим я согласен, но все остальное — это отговорки, а не препятствия. Нет 1000 серверов, не переводите весь кластер сразу, используйте постепенный ввод новой версии и сплит-тестирование. Нагрузка — то-же самое.
Иногда 1000 серверов — это не 1000 одинаковых независимых серверов, а единая система, и сервера постоянно взаимодействуют друг с другом. И проблема не в том, как ведёт себя каждый из них, а как они все вместе себя ведут. Например, в случае p2p взаимодействия количество внутренних связей растёт квадратично, а ресурсы каждого из серверов не растут совсем. Оценить поведение подобной системы по уменьшенной в N раз модели не всегда возможно. А с нагрузкой, простите, что то же самое? Я уже привёл пример, когда ошибку даже при нагрузочном тестировании сложно отловить.
Несколько сотен терабайт… Ну если их надо сохранить, то да дисков для тестов может и не быть, но если их нужно передать и обработать, то ничего страшного в этом не вижу.
Прогнать по сети сотню терабайт уже не быстро, но я всё же хранение имел в виду.
Есть множество людей, которым некомфортно работать в подобных условиях, и они (люди) не становятся от этого плохими. Достаточно при устройстве на работу спросить, а могут ли подобные штуки случаться, и если могут — то просто не идти туда. А кому-то решать подобные проблемы на живую нравится, и просто каждый день программировать от звонка до звонка скучно.
Вообще, в случае проблемы в продакшене обычно есть два варианта развития событий. В первом люди ищут пути скорейшего разрешения проблемы и помогают друг другу. Во втором ищут пути, как бы скинуть с себя ответственность. Судя по вашему ответу, вы придерживаетесь второго варианта. Я работал в компании, в которой тоже делали так. К счастью, на текущем месте работы мы занимаемся решением проблем.
Вы можете являться адептом чего угодно, но формат хранения данных иногда меняется, по объективным и веским причинам. Приведу простейший пример: лет 10 назад FAT конвертировали в NTFS для возможности хранения 4ГБ образов DVD дисков, обратно отконвертировать уже нельзя.
Невозможно протестировать всё. Если вы эмулируете среду заказчика — вы уже получаете не идентичный стенд. Иногда просто невозможно создать идентичное окружение: если в продакшене 1000 серверов, то ещё одной тысячи для тестирования может и не оказаться, или физически некуда поставить, неоткуда взять питание. Залить/сгенерировать несколько сотен терабайт данных тоже большая проблема. Сделать нагрузку, идентичную продакшену, сложно и затратно в плане ресурсов. Я уж не говорю про многопоточный код, race далеко не каждый раз появляется даже при нагрузочном тестировании.
Вот вам пример на счёт тестирования: пишете код, как в этом примере из официальной документации, получаете дедлок, который появляется с очень маленькой вероятностью. Отловить такое при тестировании, даже при наличии нагрузочных тестов, крайне сложно.
Иногда откатываться некуда :) Редко, но бывает. Вы сконвертировали базу, пожили с ней неделю, и всё сложилось так, что появился страшный баг. Вы не можете уже откатиться без потери информации, а чинить надо. Или пиар акция уже назначена, и починить в итоге всё равно надо быстро, даже откатываясь. А вот как раз для эксплуатации аврала нету, откат — штатная операция, они всегда к этому готовы.
Альтернативная история из мира разработки на заказ: продукт надо отдавать заказчику через 3 дня, но нашёлся Страшный Баг, который не проявлялся из-за особенностей тестового окружения.
5 см — это очень серьёзно, уже антенна начинает сильно влиять. Как в итоге решили задачу?
У всяких модных авиалайнеров лазерные оптически гироскопы и макромеханические (не знаю, как правильно назвать) акселерометры. digilander.libero.it/andreatheone/irs.htm
Простите, 10 герц, сейчас в документацию глянул. Откуда 20 взялось — не знаю даже. Например S1315F-RAW, пара в rtk режиме как раз даст дециметровую точность даже с фиговенькими антеннами. Брал два за 100 евро. Вроде недорого. Ещё на NV08C-CSM можете посмотреть, отечественная разработка же.
Почему не получится корректировать в динамике при не единичной матрице измерений? Коптеры же как-то стабилизируются по углам (т.е. висят горизонтально и можно задавать горизонтальные скорости стиками) без gps приёмников, по горизонтали и рысканью только дрейфуют. Тем более, что GPS даёт только 3 координаты и вектор скорости, а углы узнать не позволяет.
То, что их надо починить в кратчайшие сроки (сервис почти не работает, пользователи волнуются, у менеджеров седеют волосы на попе), а баг то ещё найти надо и понять, как чинить. Для меня это стресс в положительном смысле, это драйв и челлендж. А для кого-то это перенапряг, ему надо спокойно думать, погулять в парке и т.д.
Грузик будет отличный маятником с внешним подводом колебаний, а упругий ус — пружиной. То есть от наматывания лески скорее всего защититься получится, но сразу появится много других проблем. Даже если между домами всего 30 метров (обычно в такой ситуации не будет никаких деревьев и проще ножками спуститься и 2 троса связать снизу), то лески надо будет метров 50 выпустить, а это уже нефиговый такой парус.
Я не против, не подумайте, идея клёвая. Но подводных камней больше, чем кажется на первый взгляд. Пропеллеры дерутся очень-очень больно, коптером по голове получить тоже неприятно.
Я показания акселерометров интегрировать по вертикали не предлагал :) Я предлагал использовать направление вектора ускорения свободного падения для коррекции ухода углов тангажа и крена в стабилизированном полёте. Возможны нюансы типа очень пологого скоординированного разворота, когда отличия в 5-6 знаке могут начать играть роль. Но навскидку кажется, что шумы недорогих mems датчиков сильно больше. Так то и g зависит от широты, и от высоты, и направлено не всегда в центр геоцентрической системы координат, но сколь велики эти погрешности по сравнению с шумами? Скоро дособираю квадрик, посмотрю на практике.
СНС — хорошее решение, когда есть в наличии открытое небо. Кстати, сейчас уже недорого можно получать координаты с частотой 20 Гц и дециметровой точностью. С барометром, сами знаете, куча подводных камней, начиная с получения статического давления, и заканчивая погодными условиями. Пожалуй, если исключить СНС, то датчиков, которые дают абсолютные координаты, совсем мало: магнетометр (может внезапно показать куда угодно из-за местных аномалий), барометр (тучка пришла — давление у земли поменялось — вошёл в землю) да трубка Пито (да и так даёт координаты относительно воздуха, а не земли). Ну, с натяжкой, пирометр. На больших ЛА радиовысотомер ещё есть, а на мелких изредка — лазерный или ультразвуковой. Придётся интегрировать и страдать от шумов и дрейфа, куда деваться.
Кстати, на сколько я в курсе, навигационная система современных пассажирских самолётов, типа A320, в полностью автономном режиме (т.е. без получения координат GPS) даёт ошибку по горизонтали порядка 1 километра на 200 километров пути, пройденных на крейсерской скорости. Вполне себе неплохой результат.
Плюс много. Решать интересные задачки, да ещё и в режиме диалога с интервьюерами — круто.
Те, кто пишет про стресс, что для программиста главное — спокойствие, скажите: а ошибки в продакшене вы как чините, совсем без стресса, да? Только не надо говорить, что их не бывает, если правильно тестировать и бла-бла-бла.
На сколько я понимаю, шум mems ДУСов (в народе — гироскопов) можно частично победить используя показания акселерометров и фильтр Калмана, в котором присутствует модель собственно БИНС. То есть углы, полученные просто интегрированием показаний гироскопов, уплывают быстро, даже если фильтры использовать. А если увязать углы с показаниями акселерометров и со знанием, что мы находимся на планете Земля, у нас тут есть ускорение свободного падения, направленное вниз в локальной системе координат, связанной с поверхностью планеты, и оно равно 9.8 м/с, и что оси ДУСов и акселерометров жёстко связаны — то всё становится намного веселее.
Тяга винта зависит ещё и от скорости воздуха вдоль оси вращения винта, угол атаки будет меняться. Коптерам практически пофигу, они вертикально вверх на скорость редко летают, а при горизонтальном полёте составляющая скорости по оси вращения винтов не такая уж и большая. Обычно берут винты, которые дают большой момент в статике (слоуфлаеры).
Сегодня утром мне пришла в голову замечательная аналогия. Представьте себе Википедию, в которой нет строки поиска. Если хотите прочитать про что либо, вам надо правильно ввести термин в пути к статье. И в статьях нет ссылок, узнать, есть ли статья по какому-либо слову можно опять же вбиванием полного адреса в браузере. Это прослушка по ордеру. Прослушка без ордера — это поисковая строка и ссылки. Появляется возможность использовать мощнейший инструментарий по обработке информации, появившийся за последние 10 лет. Можно не раскрывать уже случившиеся преступления, а предотвращать их! А это уже очень важное отличие, потому что это спасение человеческих жизней.
АНБ достаточно объявить, что они предотвратили пару террактов типа Бостонского, и всё, мнение общественности на их стороне. Потому что для большинства жизнь важнее, чем тайна частной жизни. На втором месте, кстати, скорее всего деньги и семья. Если кому-то privacy важнее — добро пожаловать в Сомали.
Что же касается Сноудена, чем он думал, когда шёл на работу в подрядчика разведывательной организации?
Про постепенный ввод нагрузки — вы опять забыли, что этап перехода на новую версию позади и откатываться уже некуда. Для зеркалирования внешней нагрузки на тестинг нужно решить нетривиальную, в общем случае, задачу по поддержанию одинакового внутреннего состояния систем (продакшена и тестинга). В простейшем случае — базы данных должны быть синхронны, иначе будут сыпаться ошибки. Для этого вам надо либо посылать ВСЕ запросы в тестинг (и он должен быть размером с продакшен), либо делать срезы, но это тоже сложно. Есть много вариантов, но, опять же, невозможно протестировать всё.
Если у менеджера седеют волосы — это не значит, что он верещит. Нормальный менеджер будет лишь спрашивать, как он может помочь, кого ещё вызвонить-позвать и т.д., то есть способствовать процессу.
Опять вы про виноватых. Прочитайте мой пример из камента выше, про буст и код из официальной документации. Кого назначаете виновным?
Не вы ли писали про виноватых?
Наверное, стоит тогда определиться, что есть стресс. Если проблему надо быстро найти и решить, работая при этом с живыми данными, максимально сокращая стадию тестирования, и всё это сильно выбивается из нормального ритма работы — это стресс. Примерно как попасть в занос на машине зимой. Есть зоны ответственности, есть процедуры восстановления, но они уже не отработали, это та самая ситуация, что случается редко. Но как только случилась — действовать надо быстро, точно и слаженной командой.
Продолжая аналогию с машиной — у вас уже стоит зимняя резина, и вы вели машину аккуратно. Но покрытие оказалось коварным, ветер неудачно дунул, и машину начало заносить. Хладнокровно нажав на газ (передний привод) и подработав рулём вы выходите из заноса и продолжаете движение. Запаникуете и жмакнете на тормоз — в лучшем случае вас просто развернёт.
Заметьте, вы опять говорите про виноватых. Менеджеры, разработчики и тестировщики работают вместе, их задача — сделать качественный продукт. Если всплыл баг в продакшене, то, скорее всего, виноваты все: одни его сделали, вторые не отловили, третьи просто потому что ответственные за продукт. Вот если один и тот же баг регулярно всплывает — то что-то не так в консерватории. Кстати, совсем не понимаю, почему у QA то стресс должен быть? Ну не смогли найти ошибку, бывает, это нормально. Если косяков в самом процессе тестирования не было — то их даже премии не за что лишать.
Спокойно — это как, неспешно попивая кофеёк, а в 19:00 встал и пошёл домой? Фиговенький тогда сервис, прямо скажем. Повторюсь, это ситуация, когда некуда откатываться, чинить надо здесь и сейчас. Или вы говорите про быстро и уверенно? Но темп работы всё равно же будет отличаться от обычного.
Иногда 1000 серверов — это не 1000 одинаковых независимых серверов, а единая система, и сервера постоянно взаимодействуют друг с другом. И проблема не в том, как ведёт себя каждый из них, а как они все вместе себя ведут. Например, в случае p2p взаимодействия количество внутренних связей растёт квадратично, а ресурсы каждого из серверов не растут совсем. Оценить поведение подобной системы по уменьшенной в N раз модели не всегда возможно. А с нагрузкой, простите, что то же самое? Я уже привёл пример, когда ошибку даже при нагрузочном тестировании сложно отловить.
Прогнать по сети сотню терабайт уже не быстро, но я всё же хранение имел в виду.
Есть множество людей, которым некомфортно работать в подобных условиях, и они (люди) не становятся от этого плохими. Достаточно при устройстве на работу спросить, а могут ли подобные штуки случаться, и если могут — то просто не идти туда. А кому-то решать подобные проблемы на живую нравится, и просто каждый день программировать от звонка до звонка скучно.
Вы можете являться адептом чего угодно, но формат хранения данных иногда меняется, по объективным и веским причинам. Приведу простейший пример: лет 10 назад FAT конвертировали в NTFS для возможности хранения 4ГБ образов DVD дисков, обратно отконвертировать уже нельзя.
Невозможно протестировать всё. Если вы эмулируете среду заказчика — вы уже получаете не идентичный стенд. Иногда просто невозможно создать идентичное окружение: если в продакшене 1000 серверов, то ещё одной тысячи для тестирования может и не оказаться, или физически некуда поставить, неоткуда взять питание. Залить/сгенерировать несколько сотен терабайт данных тоже большая проблема. Сделать нагрузку, идентичную продакшену, сложно и затратно в плане ресурсов. Я уж не говорю про многопоточный код, race далеко не каждый раз появляется даже при нагрузочном тестировании.
Вот вам пример на счёт тестирования: пишете код, как в этом примере из официальной документации, получаете дедлок, который появляется с очень маленькой вероятностью. Отловить такое при тестировании, даже при наличии нагрузочных тестов, крайне сложно.
Альтернативная история из мира разработки на заказ: продукт надо отдавать заказчику через 3 дня, но нашёлся Страшный Баг, который не проявлялся из-за особенностей тестового окружения.
У всяких модных авиалайнеров лазерные оптически гироскопы и макромеханические (не знаю, как правильно назвать) акселерометры. digilander.libero.it/andreatheone/irs.htm
Почему не получится корректировать в динамике при не единичной матрице измерений? Коптеры же как-то стабилизируются по углам (т.е. висят горизонтально и можно задавать горизонтальные скорости стиками) без gps приёмников, по горизонтали и рысканью только дрейфуют. Тем более, что GPS даёт только 3 координаты и вектор скорости, а углы узнать не позволяет.
Я не против, не подумайте, идея клёвая. Но подводных камней больше, чем кажется на первый взгляд. Пропеллеры дерутся очень-очень больно, коптером по голове получить тоже неприятно.
СНС — хорошее решение, когда есть в наличии открытое небо. Кстати, сейчас уже недорого можно получать координаты с частотой 20 Гц и дециметровой точностью. С барометром, сами знаете, куча подводных камней, начиная с получения статического давления, и заканчивая погодными условиями. Пожалуй, если исключить СНС, то датчиков, которые дают абсолютные координаты, совсем мало: магнетометр (может внезапно показать куда угодно из-за местных аномалий), барометр (тучка пришла — давление у земли поменялось — вошёл в землю) да трубка Пито (да и так даёт координаты относительно воздуха, а не земли). Ну, с натяжкой, пирометр. На больших ЛА радиовысотомер ещё есть, а на мелких изредка — лазерный или ультразвуковой. Придётся интегрировать и страдать от шумов и дрейфа, куда деваться.
Кстати, на сколько я в курсе, навигационная система современных пассажирских самолётов, типа A320, в полностью автономном режиме (т.е. без получения координат GPS) даёт ошибку по горизонтали порядка 1 километра на 200 километров пути, пройденных на крейсерской скорости. Вполне себе неплохой результат.
Те, кто пишет про стресс, что для программиста главное — спокойствие, скажите: а ошибки в продакшене вы как чините, совсем без стресса, да? Только не надо говорить, что их не бывает, если правильно тестировать и бла-бла-бла.
Тяга винта зависит ещё и от скорости воздуха вдоль оси вращения винта, угол атаки будет меняться. Коптерам практически пофигу, они вертикально вверх на скорость редко летают, а при горизонтальном полёте составляющая скорости по оси вращения винтов не такая уж и большая. Обычно берут винты, которые дают большой момент в статике (слоуфлаеры).