Небольшая уборка перед тем, как мы начнем. Мы превратили этот еженедельный пост в Информационную рассылку, на которую теперь можно подписаться. Мы продолжим публиковать этот пост в нашем блоге, но если вы предпочитаете электронную почту и формат информационного бюллетеня, этот вариант теперь доступен для вас.

Кроме того, я немного изменил формат. Надеюсь, это легче следовать.

Слава Богу за этого чувака, Станислав Петров — Википедия

Интересное чтение с комментариями

Райан Сингер: продукты — это функции



О продуктах легче рассуждать, если рассматривать их как функции. Они преобразуют входную ситуацию в выходную.

Это позволяет вам описать действие продукта как преобразование обстоятельств пользователя, а не набор функций.

Теперь я понял, что именно так я склонен думать обо всем. Как набор входов, выходов и некоторое преобразование этих входов в выходы. Я также понял, что это делает меня странным, поскольку большинство людей не разбирают вещи до такого уровня. Но такое мышление действительно помогает нам добраться до основ того, чего мы пытаемся достичь.

Вот как сегодня работает машинное обучение/ИИ. У нас есть входы и выходы, для которых мы уточняем алгоритмы на основе этих входов и выходов. Когда мы говорим о «черном ящике» таких вещей, как нейронные сети, это признание того, что мы на самом деле не понимаем «функции» или «процесса». Мы просто знаем, что при заданном наборе входных данных мы получаем этот набор выходных данных. Это то, что мы ищем. И если мы применим это к другим входным данным, мы обычно (это важная часть) получаем ожидаемые результаты.

Даже если ничего из этого не имеет для вас смысла, я надеюсь, что пример в статье о календаре покажет вам, почему «старый способ» ведения дел был ошибочным. Хороший владелец продукта, следующий продуктовому мышлению, делает именно то, что показано в этой статье. Мы исследуем входы и выходы с помощью множества различных процессов и практик (опросов, интервью, экспериментов, наблюдений), а затем пытаемся найти «f». И действительно хороший ученый (владелец продукта) затем проводит эксперименты с f, чтобы убедиться, что он дает нужные нам результаты для заданных входных данных.

Мне это нравится:

Наконец, функциональное представление сочетается с причинно-следственными связями. Клиенты принимают решения в ситуациях для достижения результатов, а не просто на основе симпатий и антипатий. Эта структура заставляет вас думать о том, что происходит до и после того, как они используют продукт.

Тестирование в продакшене — построение наблюдаемых распределенных систем



Одна из реакций на множество случаев сбоев, с которыми мы сталкиваемся в распределенных системах, – это дополнительное тестирование. К сожалению, тестирование — это мера проверки правильности системы — мы просто не можем предсказать случаи сбоев, которые произойдут в продакшене. Более того, любая среда, которую мы используем для проверки поведения системы, в лучшем случае является бледной имитацией нашей производственной среды. Альтернативой добавлению дополнительных тестов является добавление дополнительных средств мониторинга и предупреждений, чтобы мы как можно скорее знали, что система показывает признаки деградации. К сожалению, мониторинг и оповещение страдают теми же недостатками, что и тестирование — мы отслеживаем поведение, которое является предсказуемым по своей природе или с которым мы сталкивались в прошлом. Вместе мониторинг и тестирование пытаются перечислить все возможные сочетания частичного и полного отказа системы. К сожалению, они только моделируют то, как вы ожидаете, что система будет работать в действии.

Черт возьми! Кевин всегда пишет статью, о которой думаю написать я. Хотя в данный момент мне интересно, не медлю ли я, зная, что Кевин возьмет на себя мою слабину. Конечно, моя версия этого была бы еще более хардкорной. Я надеюсь вскоре выпустить подкаст, в котором я обобщу свои чувства по этому поводу, но в то же время, почему у нас так много проклятых сред? Как отмечает Кевин, важно только производство. Это тот, с вашими клиентами. Все остальное имитация. Модель. Сколько вы действительно можете получить от использования моделей? Я думаю, нормальное количество при разработке. Но я думаю, что на этом все заканчивается.

И это:

Разница между производственной и любой промежуточной средами может существенно повлиять на стабильность службы.

Действительно, действительно важно.

Так же отличный график:

Внедрение экспериментов с хаосом в конвейеры журналов безопасности | OpenSource.com



Команды безопасности полагаются на высококачественные журналы для большинства профилактических мероприятий по обеспечению безопасности. Предотвращение возникновения инцидента требует наблюдаемой информации о том, откуда может произойти сбой, и журналы являются одним из важных источников такой информации. Когда происходит инцидент, организации должны быть в состоянии реагировать и локализовать его как можно быстрее. Журналы необходимы не только для поиска источника проблемы, но и для определения соответствующих контрмер.

Но что происходит, когда у организации нет нужных данных журнала? Когда происходит неизвестное или непредвиденное событие, как мы можем понять, почему мы его не предвидели?

Так что я фанат хаос-инжиниринга. Но я хочу кое-что обсудить.

Однако конечной целью создания хаоса в системе безопасности является обучение посредством тщательных и методичных экспериментов с системами. Наш подход заключается в том, чтобы вносить сбои в определенные компоненты, чтобы выявить неизвестные и непредвиденные проблемы в системе до того, как они повлияют на операционную целостность основных продуктов и услуг для бизнеса.

Это правда. Но это тебя не спасет. Будут новые проблемы. Это сложные системы. Появится неожиданное поведение. Я не говорю, что мы должны сдаться. Мы должны запустить эти тесты и поймать то, что сможем. Но самое главное, мы должны относиться к этим тестам как к практике. Практикуйтесь в решении проблем, когда они возникают. Таким образом, эта практика должна максимально имитировать процессы производственной обработки. Поскольку проблемы неизбежны, мы хотим быть готовыми. А практика — лучший способ подготовиться должным образом.
Так же как и тестирование хаоса. Но не обманывайте процесс, чтобы справиться с проблемами, потому что «мы нашли проблему и исправили ее как можно скорее — это самое главное». Это может быть. Но даже тогда не стоит обманывать процесс. Выполните в точности те шаги, которые вы бы сделали, если бы эта проблема была обнаружена в рабочей среде и/или клиентом.

Быстрые удары

Новости / Случайные

Системы / Инфраструктура / Облако

Программирование

Математика / Наука / Поведение / Экономика

Блокчейн/Криптовалюта

ИИ/машинное обучение/наука о данных/статистика

Если вам нужна помощь с вашей архитектурой или организацией разработки, не стесняйтесь обращаться к нам: realkinetic.com @real_kinetic

Вы можете подписаться на меня напрямую @lyddonb

Подпишитесь на рассылку Real Kinetic