Недавно я был особенно впечатлен одной вещью.В качестве вступления я хотел бы поговорить с вами: когда мы проводили некоторые эксперименты по моделированию экстремальной регрессии трафика внутри компании, мы наблюдали аномальное использование ЦП на TiKV (компонент распределенного хранилища TiDB).Тем не менее, мы Мы не заметили каких-либо аномалий в наших показателях Grafana Metrics и выводе журнала, поэтому несколько дней мы были в замешательстве. Наконец, старый драйвер вслепую угадал и в сочетании с профилированием нашел настоящего убийцу. Настоящий убийца появлялся в неожиданных местах. Местонахождение: журнал модуль для отладки (для уточнения: эта ошибка в настоящее время исправлена, и триггер этой ошибки появится только в очень экстремальных стрессовых сценариях + уровень журнала полностью включен, пожалуйста, будьте уверены). Эта статья не анализ ошибок, я думаю, что важнее инструменты, которые мы используем в процессе поиска проблем и процесс мышления старых драйверов.
Как наблюдатель, я видел восхищенные взгляды молодых коллег, наблюдающих за тем, как старые водители умело оперируют perf и переключаются между различными инструментами и интерфейсами, и смутно чувствовал, что что-то не так:Это означает, что ремесло не может быть воспроизведено.Впоследствии я провел некоторое исследование пользовательского опыта базового программного обеспечения и обнаружил, что теории и данных в этой области действительно очень мало (большинство из них — это исследования продуктов ToC, а системное программное обеспечение, вероятно, связано только с философией UNIX). школа), и в ней отсутствует систематизация и она опирается на Зависит от личного "вкуса" автора, но явно есть хороший и плохой программный опыт. Например, когда опытный инженер увидит инструмент командной строки, он поймет, является ли он прост в использовании и является ли это инструментом "со вкусом". Часто причина, по которой «вкус» называется «вкусом», заключается в том, что он неясен и непонятен. Это, безусловно, проявление артистизма в разработке программного обеспечения, но это также означает, что его нельзя скопировать или изучить.
Я тоже не думаю, что это хорошо.Сегодняшняя статья и, возможно, следующие несколько статей (хотя я не знаю, что написать в следующих нескольких статьях, но сначала поставлю флажок) попытаются обобщить, где хороший базовый опыт работы с программным обеспечением исходит из. Как и первая статья, эта статья будет посвящена двум важным темам: наблюдаемости и интерактивности. Что касается того, почему мы говорим об этих двух моментах вместе, я сначала продам его, а затем расскажу об этом в конце.
наблюдаемость
Что такое наблюдаемость? Это из моего поста двухлетней давности«Наблюдаемость распределенной системы в моих глазах»[1] Это можно увидеть в статье, и здесь я не буду повторять одно и то же содержание. С углублением практики наблюдаемости в TiDB у нас появляется более глубокое понимание этой темы.Для лучшего понимания сначала проясним вопрос: когда мы говорим о наблюдаемости, кто наблюдает?
Кто наблюдает?
Многие друзья могут быть ошеломлены на мгновение, думая: Излишне говорить, что это должен быть человек, а не машина. Да, люди действительно наблюдают, но такая простая истина часто игнорируется разработчиками программного обеспечения, так в чем же между ними разница? Почему важно акцентировать внимание на человеке?
Чтобы ответить на этот вопрос, нам нужно четко понимать реальность: кратковременная рабочая память людей очень ограничена. Большое количество психологических исследований показало, что емкость рабочей памяти человека составляет примерно всего 4, то есть для того, чтобы сосредоточиться на 4 элементах информации одновременно в краткосрочной перспективе [2], и больше информации необходимо запоминать модулями. , например, как мы быстро запоминаем номера телефонов, Возьмем для примера 13800001111, мы обычно не переносим числа по одному, а группируем их в виде: 138-0000-1111. После понимания некоторых основных предположений и пропускной способности ментальной модели человека, я думаю, многие разработчики системного программного обеспечения, вероятно, перестанут хвастаться: мое программное обеспечение имеет более 1000 элементов мониторинга! Это не только нехорошо, но и позволяет большему количеству информации разрушить формирование кратковременной памяти, вносит больше шума и заставляет пользователей проводить много времени в море информации в поисках ключевой информации, а также как бессознательная классификация (я считаю, что бессознательная фоновая задача мозга состоит в том, чтобы индексировать и классифицировать информацию, обратите внимание, что это также потребляет пропускную способность), поэтому первый вывод: лучше всего иметь только 4 ключевых информации в интерфейсе программного приложения на одном экран. Итак, следующий вопрос: что является ключевой информацией? Что такое шум?
Отличать важную информацию от шума
Стандартного ответа на этот вопрос нет. Что касается системного программного обеспечения, мой опыт таков:Следите за ключевыми ресурсами. Программное обеспечение на самом деле очень простое, суть в использовании и распределении аппаратных ресурсов, уделяет внимание искусству баланса. Ключевые аппаратные ресурсы — это не что иное, как следующие: Для каждого из следующих ключевых ресурсов в определенный период времени выборки (отдельная точка не имеет большого значения) вы можете получить общую картину состояния работы системы, задав несколько простых вопросов. вопросы :
- ЦП: Какие потоки работают? Что делают эти темы? Сколько процессорного времени потребляет каждый из этих потоков?
- Память: что в данный момент хранится в памяти? Частота попаданий этих вещей? (обычно нас больше интересует кэширование бизнеса)?
- Сетевой ввод-вывод: Есть ли отклонения в QPS/TPS? Каковы текущие основные запросы сетевого ввода-вывода? Достаточно ли пропускной способности? Задержка запроса? Длинная ссылка или короткая ссылка (мера накладных расходов системного вызова)?
- Дисковый ввод-вывод: диск читает и записывает файлы? Какие файлы читаются и записываются? Какова схема большинства операций чтения и записи? Насколько велика пропускная способность? Какова задержка ввода-вывода?
- Ключевые журналы: не все журналы полезны, только журналы, которые содержат определенные ключевые слова, будут интересны людям. Итак, есть ли какие-либо журналы для определенных ключевых слов?
Путем истязания души вышеуказанными стандартными вопросами вы точно сможете иметь определенное представление о рабочем состоянии системы.
- Еще одним ключевым моментом является то, что метрики этих систем должны быть связаны с бизнес-контекстом, чтобы быть полезными.Например, для базы данных, которая поддерживает транзакции, предположим, что мы видим потоки ЦП и стеки вызовов и обнаруживаем, что много процессорного времени Когда дело доходит до таких вещей, как ожидание, сон, бездействие, других узких мест в ресурсах ввода-вывода нет. В настоящее время, если вы посмотрите только на эти цифры, вы можете быть сбиты с толку, но в сочетании с частотой конфликтов транзакций это может быть ярким, или даже возможным.Более полезная информация для наблюдателя, чтобы прямо дать, какие транзакции и даже какие конфликты строк тратятся во время ожидания этих блокировок.
Это не значит, что другая информация бесполезна, но ценность значительного количества информации апостериорна, например, большая часть журналов отладки, или та вспомогательная информация для подтверждения догадки, на самом деле почти бесполезна при решении неизвестных задач. Помощь, но также требует, чтобы наблюдатель имел много фоновых знаний, такого рода информацию лучше всего представлять в сложенном виде, лучше с глаз долой. Если вы откроете внутреннюю Grafana TiDB, то увидите множество таких индикаторов, например, stop-conditions-changed-of-each-cf (хотя я знаю значение этого индикатора, но, думаю, 99% пользователей TiDB не знают ) , а по названию я увидел внутреннюю борьбу инженера, написавшего это имя.Он, должно быть, хотел, чтобы другие люди (или он сам) поняли, к чему относится это имя, но, к сожалению, по крайней мере, у меня здесь не получилось. Что дальше для наблюдения?действовать.Подумайте, прежде чем действовать, какова предпосылка действия? Наши действия по решению проблем примерно следуют следующему шаблону (моё собственное резюме, но в любой книге по когнитивной психологии будут подобные концепции):Наблюдение -> обнаружить мотивацию -> догадка -> проверить догадку -> составить план -> действовать, затем вернуться к наблюдению, повторяя цикл.Важнейшей частью этого внутреннего человека (или опыта старого водителя) является связь от наблюдения к догадке Что же касается мотивов наблюдения, то их всего два вида:
- Устранение непосредственных неисправностей;
- Избегайте потенциальных рисков (избегайте будущих неудач).
При условии, что в системе нет проблем, вносить изменения не требуется. Я думаю, что эти два шага важны, потому что в основном другие ссылки можно автоматизировать, но эти два шага сложны, потому что их нужно использовать:Человеческие знания/опыт и интуиция.Для системы с хорошей наблюдаемостью обычно мастер может хорошо использовать человеческую интуицию.Приведу небольшой пример: при открытии фонового интерфейса системы мы стараемся не обращать внимания на конкретную текстовую информацию.Если в интерфейсе есть много красных и желтых цветовых блоков на экране, и наша интуиция подскажет нам, что эта система может быть в нездоровом состоянии.Далее, если красный и желтый цвета грубо сконцентрированы в определенной позиции на экране, наше внимание обязательно будет сосредоточено на это положение; если интерфейс весь зеленый, он должен быть в работоспособном состоянии. Как максимально использовать человеческую интуицию? Или куда вести? Я думаю, что лучшие моменты:Прогнозирование риска.
Где используется человеческая интуиция? предсказание риска
Здесь требуются некоторые предварительные знания. Прежде чем говорить на эту тему, хотелось бы поделиться небольшой историей, которую я слышал раньше.В то время на заводе Форд сломался мотор,и тут я нашел старого хозяина.Он послушал звук,посмотрел на работу станка, и в конце концов б/у Мелом нарисовал линию на моторе, сказав, сколько раз катушка была намотана в этом месте, и скептически настроенные рабочие сделали то же самое, и проблема была решена, а затем мастер взял плату за ремонт 10 000 долларов США (по тем временам это была заоблачная цена), босс Форда спросил его, почему с него столько взяли за проведение линии, и мастер выставил счет: 1 доллар за проведение линии и 9 999 долларов за знание места провести линию.
Давайте не будем говорить о том, правдива эта история или нет. Если предположить, что это правда, мы можем увидеть интуицию и опыт, и это действительно может создать большую ценность. Моя первая реакция, когда я услышал эту историю, была такой: этот старый мастер должен увидеть это. ситуация.Есть еще много (ерунда), и этот вопрос должен быть общей проблемой. На самом деле, самая сложная часть решения задачи – это устранение большинства ненадежных направлений путем наблюдения (особенно некоторых характерных точек), кроме того, необходимо верить, что причины общих неисправностей сойдутся. В настоящее время первым шагом системы с хорошей наблюдаемостью является руководство интуицией пользователя.Это направление требует знания предшественников, чтобы указать наиболее вероятные точки отказа и соответствующие индикаторы (такие как использование ЦП и т. д.); Второй шаг — показать это с помощью некоторых психологических трюков. О следующем свидетельствует TopSQL, небольшая функция, которая будет представлена в TiDB. Об этой функции также очень просто сказать. Мы обнаружили, что многие сбои пользователей связаны с небольшим объемом SQL. Характеристика этого типа SQL заключается в том, что он имеет процессорный след, который значительно отличается от других SQL, но размер каждый SQL выглядит независимым, это нормально, поэтому функция TopSQL состоит в том, чтобы ответить: сколько процессор потребляет? На каком SQL? Я стараюсь не интерпретировать приведенный ниже скриншот, я думаю, вы сразу поймете, как его использовать, если вы сообразительны:
Ваша интуиция подскажет вам, что соотношение плотного зеленого во второй половине, кажется, отличается от других. Это увеличивает общую загрузку процессора, и кажется, что что-то не так. Да, это, вероятно, правильное направление. визуализация может использовать человеческую интуицию, чтобы быстро обнаружить основное противоречие.
Что такое "операция"? Определение истинного жизненного цикла операции
Когда я писал только что первый пункт, я подумал о другом ключевом ресурсе, который часто упускают из виду: о времени. Первоначально я хотел указать время в разделе ключевых ресурсов, но, подумав, может быть, будет более уместно указать его здесь.
С метафизической точки зрения, все наши нынешние компьютеры являются реализациями машин Тьюринга.Минимальный функциональный набор языка, полного по Тьюрингу, я знал еще с начальной школы: чтение/запись переменных, переходы и циклы. Говоря литературным языком, так называемая программа - это бесконечное число реинкарнаций, большая реинкарнация вложена в малую реинкарнацию (петлю), и в каждой реинкарнации непрерывно делается выбор (ветвь) в соответствии со статус-кво (переменная) . Когда я говорю это, проницательные читатели могут догадаться, что я пытаюсь сказать:Нет смысла говорить о наблюдаемости вне циклов.Определение цикла является гибким.Для людей большой цикл, очевидно, представляет собой всю жизнь, малый цикл может составлять один день в году, или даже цикл не может использовать промежуток времени как единицу, например, цикл работы. .. Для программного обеспечения базы данных, Другими словами, что такое разумный цикл? Является ли цикл выполнения SQL? Или транзакцию от Begin до Commit ? Здесь нет стандартного ответа, но мое личное предложение,Чем ближе цикл к сценарию использования конечного пользователя, тем он практичнее.Например, в базе данных выбор выполнения одного SQL в качестве цикла не так хорош, как выбор цикла транзакции, а цикл транзакции не так хорош, как цикл запроса приложением полной ссылки. На самом деле, TiDB представила OpenTracing очень рано, чтобы отслеживать, какие функции вызываются и сколько времени затрачивается на цикл выполнения SQL, но он применялся только на уровне SQL TiDB (друзья, знакомые с нами, должны знать наши SQL и хранилище (разделено), это не реализовано в уровне хранения TiKV, поэтому будет тупик, когда процесс выполнения SQL-оператора сгонит до TiKV; позже мы реализовали функцию передачи TraceID и SpanID в TiKV Он был изначально доступен, и по крайней мере картина одного цикла стала более полной.Мы изначально планировали остановиться на этом, но потом случилась мелочь.Однажды клиент сказал: Почему мое приложение так медленно обращается к TiDB? Потом я взглянул на мониторинг TiDB.Нет, в основном это занимает миллисекунды, чтобы вернуть SQL в базу данных, но заказчик сказал: Видите ли, я больше ничего не сделал с этим запросом.Почему две стороны не могут совпадение? Позже, после того, как мы добавили Tracer, мы обнаружили, что что-то не так с сетью на стороне клиента. Этот случай напомнил мне, что если трассировка всей ссылки может быть достигнута, вся ссылка здесь должна быть рассчитана из запроса бизнес-стороны, и имеет смысл смотреть только на жизненный цикл. Следовательно, после этого, расширив переменную сеанса в TiDB, мы можем помочь пользователям передавать информацию трассировщика протокола OpenTracing в систему TiDB через переменную сеанса и открыть бизнес-уровень и уровень базы данных, которые действительно могут реализовать полный отслеживание жизненного цикла. , эта функция также встретит вас в самой ближайшей будущей версии.
Сказав так много, вот несколько моментов:
- Время также является важным ресурсом.
- Очень важно выбрать правильный цикл, будь то захват образца или выполнение трассировки.
- Чем ближе цикл к циклу бизнеса, тем он полезнее.
Момент, когда наблюдаемые спасают жизни: ретроспектива
Я считаю, что никто не будет смотреть на интерфейс мониторинга каждый день, на самом деле, если подумать, когда нам нужна наблюдаемость, большинство из них уже испытали ощутимые сбои или очень явные риски. Система в это время, возможно, была «смертельно больна», или когда горели брови, они не знали причины, первопричины или каких-то менее очевидных аномальных изменений в определенное время до этого. в дополнение к обычным Метрикам Больше информации нет.Конечно, мы не всегда будем открывать Профилировщик ЦП.Обычно Профилировщик запускается вручную, но если это для просмотра причины после события, может быть Профиль ЦП запись до инцидента. Поскольку это очень поможет, лучшим решением будет:Автоматически открывать Profiler через относительно короткий интервал времени (например, минуты) и автоматически сохранять результаты диагностики., точно так же, как делать регулярный подробный медицинский осмотр, просто регулярно удаляйте старую запись.В случае аварии вы можете быстро вернуться и более эффективно спасти свою жизнь.
Кроме того, поверьте мне, при выполнении профиля нет явной потери производительности (не говоря уже о периодической). Мы называем эту функцию: Непрерывное профилирование. Эта функция очень практична и скоро встретится с вами. Согласно нашему опыту, в сочетании с приведенным выше разделом, при полной системе трассировки большая часть процесса отладки может найти основную причину проблемы в Tracing + Log.
Лучшая наблюдаемость — это возможность инструктировать пользователя: «Что мне делать дальше?»
Вышеупомянутые действия, я обнаружил особенно интересное явление, когда наблюдал, как мастер справляется с проблемами: опытные разработчики всегда могут быстро пройти наблюдение и решить, что делать дальше, без необходимости сверяться с данными или ждать. вы полностью находитесь в состоянии потока (например, если вы видите данные в TiDB, которые неравномерно распределены внутри кластера или имеют горячие точки, вы будете знать, что нужно изменить стратегию планирования или вручную разделить регионы), но новички всегда будут застревать на этом шаге Собираюсь, либо идти в гугл, либо заходить в документ, внутренняя ОС: "Я вижу проблему, что мне тогда делать?" В это время, если система может дать какие-то индикаторы, которые следует наблюдать дальше, или предложения действий, это будет более дружелюбно. В настоящее время существует не так много систем, которые могут это сделать. Если вы можете это сделать, я считаю, что ваша система уже отлично справляется с наблюдаемостью. Помещение этого пункта в конец наблюдаемости на самом деле является попыткой использовать эту тему, чтобы привести к интерактивности.
интерактивность
Прежде чем говорить об интерактивности базового программного обеспечения, я хотел бы вместе с вами сделать обзор истории компьютеров.На мой взгляд, профиль компьютерной истории — это эволюционная история взаимодействия человека с компьютером: от первой картинки, глядя на кучу я тоже не знаю, как с ним работать. До сих пор я никогда не читал руководство к iPhone и могу им пользоваться. На самом деле за этим стоит прогресс нескольких дисциплин (включая, помимо прочего, психологию, когнитивную науку, нейронауку, философии и информатики).
Возвращаясь к нашей области, область базового программного обеспечения действительно немного далека от общественности. В прошлом многие проекты были завершены инженерами. Таким людям, как мы, обычно не хватало понимания человеческой природы (без обид). Типичная логика такова: " Я человек, поэтому я понимаю людей. Я могу понять свой дизайн, а поскольку я человек, его могут понять и другие. Если другие не могут его использовать, просто зайдите в документацию (там до сих пор Отвратительное лицо)" .
Когда мы анализируем некоторые ошибки, мы часто приходим к выводу, что «пользователи не работали должным образом», но действительно ли это основная причина? У меня был несчастный случай в предыдущей компании, который произвел на меня глубокое впечатление: там была распределенная файловая система, построенная самой собой в то время, и, как и все файловые системы, она имела оболочку, которая могла поддерживать какое-то командное действие в стиле UNIX. Однажды инженер выполнил строку команды: rm -rf usr local/... (обратите внимание на пробел после usr), после чего система послушно начала удалять себя... В итоге рассмотрение этого дела не состоялось. обвинить эту операцию. Вместо этого он наказал разработчика этой системы (начальника компании в то время), потому что это был плохой дизайн взаимодействия, даже если вы подтвердите перед удалением важные папки или защитите его через систему разрешений, это не будет бывает, машина работает логично, и багов в этом месте нет (даже такое удаление действенно, ведь распределенная система ЛОЛ). За долгие годы работы инженером я постепенно понял истину:Лучшие инженеры умеют находить баланс между логикой и эмоциями.Хороший дизайн рождается из понимания технологий и психологии.В конце концов, мы пишем программы для людей.Как пользователи программного обеспечения, мы говорим не об его использовании, а о «диалоге» с программным обеспечением. Раз это диалог, значит, это интерактивный процесс Что такое хороший интерактивный опыт? Я пытаюсь обобщить некоторые принципы, написанные для разработчиков программного обеспечения, стараюсь делать это впервые и не исключаю, что добавлю позже.
Никто не читает документацию: запуск одной командой и эвристическое обучение
Согласитесь, инструкцию никто не читает. Когда мы получаем новый iPhone, первой реакцией должно быть его включение (удивительно, кажется, мы подсознательно знаем, где находится кнопка питания) Это точно не смотреть в инструкцию, чтобы найти кнопку питания, а потом начинать исследовать новый мир нашими пальцами, это очень просто, почему в области системного программного обеспечения необходимо читать документацию, прежде чем вы сможете устроиться на работу?
Я часто учу наших молодых продакт-менеджеров:«Ваши пользователи застрянут на вашей домашней странице GitHub или в разделе «Быстрый старт» вашей документации в лучшем случае на 10 секунд, и у них даже не хватит терпения прочитать документацию, и их подсознание будет искать «слова на темном фоне». " (команды оболочки), затем скопируйте содержимое в свой собственный терминал, чтобы посмотреть, что произойдет, больше ничего не поможет, если эта первая команда завершится ошибкой, больше ничего не будет, поэтому помните, что у вас есть только один шанс".Небольшой пример: когда я работал над TiUP (инструмент установки и развертывания TiDB), я неоднократно предупреждал менеджера продукта TiUP, чтобы он не использовал глупости на домашней странице, просто команду, вставьте ее, и вы можете ее использовать:
Скриншот домашней страницы TiUP (tiup.io)
На самом деле этот пример можно еще немного продолжить: я помню, как за год до эпидемии я участвовал в FOSDEM в Брюсселе, вечером общался с DevOps из Великобритании в баре рядом с местом проведения, может быть, выпил. слишком много. Он сказал:«Системное программное обеспечение, которое нельзя успешно установить с помощью одной установки apt-get, не является хорошим программным обеспечением»., слова не грубые. Тогда вы можете спросить, если действительно есть какая-то информация или концепции, которые необходимо донести до пользователей, если вы используете концепции в когнитивной психологии, которые можно назвать построением ментальной модели, то как лучше всего? Мой собственный опыт таков:исследовательское обучение. Системы, которые поддерживают этот режим когнитивного конструирования, обычно должны иметь возможность самообъяснения, то есть сообщать пользователю, что каждый шаг после первого шага (например, включение iPhone) может использовать выходные данные предыдущего шага для определения результата. завершение следующего шага. Например: системные таблицы MySQL не должны быть незнакомы пользователям MySQL. Вам нужно только использовать интерактивный клиент mysql для связи с экземпляром, и вам не нужно ждать, пока система сообщит вам, что находится в INFORMATION_SCHEMA. нужен пользователь SHOW TABLES Просто знайте, а затем используйте оператор SELECT * FROM, чтобы шаг за шагом изучить содержимое конкретной таблицы в INFORMATION_SCHEMA. Это отличный пример самоочевидности (в этом примере предполагается, что SQL используется в качестве унифицированного языка взаимодействия). Другим особенно хорошим примером является Botfather Telegram.Я думаю, что друзья, которые писали ботов для Telegram, будут впечатлены простотой использования Botfather.Прилагаю картинку, и вы поймете:
Процесс создания чат-бота с бототцом Telegram
Telegram — это программа для чата, Botfather ловко использует интерактивный режим обмена мгновенными сообщениями и применяет его к относительно скучному процессу разработки ботов вместо того, чтобы холодно бросать URL-адрес пользователю.core.telegram.org/bots/api, давайте…7s, я бы сказал, тоже люди. Желаю вам хорошего софта, которым могут пользоваться "рыбы".
Помогите пользователям подумать еще на один шаг, скажите пользователям, что нужно сделать еще полшага, и позвольте им сделать еще полшага
Я люблю читать научную фантастику, и одна из главных философских тем, которую исследует множество научной фантастики: действительно ли мы обладаем самосознанием? Как бы мы ни думали, когда программа выводит Неизвестная ошибка, вам определенно нужен голос, говорящий вам, что делать дальше, верно? Для отличного базового программного обеспечения, когда оно выдает отрицательный отзыв, лучше всего предложить разработчику, что делать дальше. Я приведу очень классический пример. Все разработчики Rust были в свое время настроены компилятором, но этот процесс не является строго болезненным. Например, см. Скриншот ниже:
Plain Text
error[E0596]: cannot borrow immutable borrowed content `*some_string` as mutable
--> error.rs:8:5
|
7 | fn change(some_string: &String) {
| ------- use `&mut String` here to make mutable
8 | some_string.push_str(", world");
| ^^^^^^^^^^^ cannot borrow as mutable
Причина, по которой это не больно, заключается в том, что компилятор четко говорит вам, где проблема, почему и что делать дальше.Обычный компилятор может напечатать не может заимствовать как изменчивый, и это правильно, но компилятор с хорошим опытом поможет вам больше Думай один шаг.
Возвращаясь к вопросу о самосознании, я уже слышал анекдот: инженер-испытатель заходит в бар и просит NaN Null, инженер-испытатель заходит в бар под видом босса, просит 500 бутылок пива и не платит. , Тысячи инженеров-испытателей пронеслись мимо дверей бара, один инженер-испытатель вошел в бар и попросил пива; DROP TABLE, и, наконец, инженеры-испытатели покинули бар довольными, затем клиент заказал жареный рис, бар Вареный LOL. Эта история говорит нам о том, что как разработчик программного обеспечения вы никогда не сможете исчерпывающе перечислить идеи пользователей.Вместо того, чтобы позволить пользователям дать волю своему воображению, лучше разработать сюжетную линию самостоятельно и позволить пользователям следовать вашим идеям шаг за шагом. Но зачем стоять на полшага? мой ответ:
- "Участие" принесет счастье. Люди иногда весьма противоречивы. Надеясь, что машина сделает все автоматически, они также ожидают, что инициатива будет у них самих. Иногда программное обеспечение уже знает, что следующим шагом должно быть какое-то действие, но предоставление оператору возможности выполнить его равносильно предоставлению оператору чувства выполненного долга.
- Право выбора остается за оператором, особенно перед лицом некоторых односторонних решений двери, идти или не идти по-прежнему следует оставлять людям.
У меня есть еще несколько предложений по этому поводу:
- Для некоторых режимов, в которых операции могут запускать несколько последовательных операций (например, сценарии развертывания терраформирования или такие функции, как изменения кластера), необходимо обеспечить пробный режим, который только выводит операции, но не выполняет операции.
- Для описанной выше операции пакетного типа создайте максимально возможную точку сохранения, не перезапуская ее каждый раз (аналогично возобновлению передачи с точки останова), опыт будет намного лучше.
- При обнаружении реальной неизвестной ошибки вам необходимо вывести различную контекстуальную информацию, чтобы помочь отладке, и, наконец, подсказать пользователю, на какую ссылку указать проблему Github в журнале ошибок, а затем лучше всего помочь пользователю заполнить заголовок проблемы. в URL-ссылке (позвольте пользователю решить, не создавать ли проблему).
Единый язык: контроллеры и объекты управления
Я брал интервью у многих системных инженеров, и у меня есть обязательный вопрос: какой ваш любимый инструмент (база данных) cli? Подавляющее большинство отвечает на redis-cli почти подсознательно. На самом деле, я бы сам ответил так же, а потом подумал, почему?
«Контроллер» — «управляемый объект» — очень распространенный режим в базовом ПО, так же, как и когда мы управляем телевизором, большую часть времени — через пульт, поэтому можно считать, что первая реакция пользователя на телевизор — «Один». и большинство контактов на самом деле являются пультами дистанционного управления, поэтому, по аналогии с базовым программным обеспечением, дизайн контроллера на самом деле очень важен.Для хорошей работы контроллера я думаю, что ключевыми моментами являются:
- Создание единого языка взаимодействия
- Непротиворечивая и лаконичная концептуальная модель
Позвольте мне использовать redis-cli в качестве примера для его интерпретации. Друзья, которые использовали redis-cli, знают, что все операции следуют шаблону [CMD] [ARG1] [ARG2].... В redis-cli нет исключений, будь то рабочие данные или изменение конфигурации, все находится под единый интерактивный язык, и этот язык понятен с первого взгляда, и в этом языке есть некоторые очень естественные соглашения, например, команды (CMD) всегда состоят из нескольких букв, не содержащих символов.
Bash
redis 127.0.0.1:6379> SET k v
OK
redis 127.0.0.1:6379> DEL k
(integer) 1
redis 127.0.0.1:6379> CONFIG SET loglevel "notice"
OK
redis 127.0.0.1:6379> CONFIG GET loglevel
1) "loglevel"
2) "notice"
Интерактивный пример redis-cli
По сути, это то же самое, что и пример MySQL в только что упомянутом разделе исследовательского обучения SQL сам по себе является унифицированным интерактивным языком, но он не такой интуитивно понятный, как Redis. Второй момент — концептуальная модель.Преимущество Redis в том, что это база данных «ключ-значение», поэтому концепция очень проста: все — это ключ-значение, и если вы посмотрите на его инструмент cli, вы узнаете, что автор пытаясь объединить все функции и взаимодействия, отображаются на эту модель Key-Value, что естественно, поскольку мы используем redis-cli, прежде всего, мы принимаем тот факт, что Redis — это база данных KV, поэтому при использовании redis-cli One из умственных предположений, которые автоматически устанавливаются в то время, является режим Key-Value, который делает все естественным при использовании cli. Это часто применяется во многих превосходных программах баз данных, таких как Oracle.Теоретически вы можете полагаться на SQL для выполнения всех операций с самим программным обеспечением, потому что пользователи должны знать реляционную модель и SQL по умолчанию, пока они используют Oracle. Говоря о положительном примере, давайте поговорим об отрицательном примере: все знают, что основной проект TiDB (исключая другие инструменты, такие как cdc, binlog) имеет как минимум 3 инструмента Controller: tidb-ctl tikv-ctl pd-ctl, хотя TiDB действительно распределенная система, состоящая из нескольких компонентов, но для пользователей большую часть времени используемый объект на самом деле является TiDB в целом (программное обеспечение базы данных), но использование нескольких ctl не то же самое, например, pd-ctl является интерактивным контроллером, и сфера влияния, вероятно, является функцией самого pd и TiKV, tikv-ctl также имеет некоторые пересечения, но он используется только для одного экземпляра TiKV, что слишком озадачивает, TiKV, очевидно, является распределенной системой а tikv-ctl это одноточечный контроллер? Итак, какой ctl следует использовать для управления TiKV? Ответ: В большинстве случаев используйте pd-ctl (сюрприз или неожиданность?). Это как у вас есть телевизор, но вам нужно использовать три пульта дистанционного управления для управления им, а пульт, который фактически управляет телевизором, называется приставкой.Эта проблема считается вопросом дизайна в повседневной жизни, но почему не кажется ли, что всеобщая терпимость в области базового программного обеспечения вдруг стала выше?
Неудивительно: Не боится неприятностей, боится неожиданности (пугает)
Я не знаю, является ли обычным явлением то, что пользователи базового программного обеспечения, сталкиваясь с ошибками (особенно из-за плохого взаимодействия), обычно сначала винят себя и чувствуют себя виноватыми, полагая, что это их собственная проблема, и редко приписывают это программному обеспечению. . Особенно, когда вы можете умело работать с каким-то сложным и разделенным программным обеспечением, многие люди будут думать, что это «навык», ведь никто не хочет, чтобы другие наблюдали за их неуклюжими операциями.
На самом деле за этим стоят глубоко укоренившиеся причины (культура хакеров имеет тенденцию немного отдавать предпочтение сложности), но я хочу сказать: это проблема с программным обеспечением! Например, я никогда не стеснялся говорить, что не буду использовать gdb не потому, что мой IQ плохой, а потому, что эту штуку очень сложно использовать. Но я видел много людей, которые действительно используют командную строку gdb для хвастовства.Возвращаясь к контрпримеру, упомянутому выше, я наблюдал, как их операторы выполняли повседневную работу и обслуживание на стороне опытного пользователя TiDB. очень опытен в переключении и работе между различными ctl.Он не думает, что есть какие-то проблемы, и даже думает, что это немного мощно.Позже я подумал об этом, приспособляемость людей все еще очень сильна, и то, что действительно беспокоит меня на самом деле нет Это не хлопотно, но когда вы делаете операцию в системе, у вас обычно есть подсознательное предположение.Например, когда имя функции "хх переключатель", ожидание пользователя при включении переключателя должно быть положительный отзыв, но пользователь будет очень расстроен, если окажется, что это не так. Вот реальная история. Мы представили новую функцию в TiDB 5.0 под названием MPP (Massively Parallel Processing), которая представляет собой массовую параллельную обработку. У нас есть конфигурация переключателя, которая называется: tidb_allow_mpp
Я не знаю, заметили ли вы проблему: в конфигурации типа переключателя, когда он установлен в положение OFF, это 100% отрицательная обратная связь, что не является проблемой, но когда проблема установлена в положение ON, это Включение функции будет зависеть от суждения оптимизатора, то есть существует определенная вероятность того, что функция MPP не сработает.Это как в комнате есть выключатель, который управляет светом.Когда его выключишь, свет не включится.Когда включишь выключатель, свет может не включиться..), ты не должен думать, что этот свет умный, вы должны думать, что свет сломан.Лучший способ написать приведенную выше конфигурацию:
tidb_mpp_mode = ON | OFF | AUTO
Мне не нужно объяснять этот метод написания, и вам не нужно читать документацию.Вы понимаете, как его использовать с первого взгляда? Хорошая конфигурация должна быть понятной. Вообще говоря, элементы конфигурации являются наиболее уязвимыми областями, которые разрушают пользовательский опыт, и мы поговорим о них позже, когда будем говорить об обратной связи.
В философии UNIX есть «принцип тишины», который гласит, что если программе нечего сказать, она должна быть тихой. Конкретным проявлением является поощрение программы командной строки к выходу с 0 в качестве кода возврата, если ей не нужно ничего выводить.На самом деле у меня есть оговорки по этому поводу.Если поведение пользователя соответствует ожиданиямВ результате, в качестве поощрения следует использовать четкий положительный отзыв (например, печать Успеха — это нормально), и не забывайте о Павлове, хозяине человеческой природы.
Обратная связь: раскрывайте прогресс, не раскрывайте внутренние детали
Я только что упомянул обратную связь, и я не думаю, что будет преувеличением назвать ее самой важной частью хорошего опыта. Друзья, изучавшие кибернетику, знают, что обратная связь — очень важная концепция, и причина, по которой самоочевидность, упомянутая ранее, является хорошим опытом, заключается в своевременности обратной связи.
Но я удивлен, что многие базовые программы спроектированы так, чтобы быть ужасно плохими в части интерактивной обратной связи.Приведу пример, с которым я знаком, когда какое-то программное обеспечение базы данных получает сложный запрос, когда вы нажимаете Enter, оно обычно просто зависает. , Там может быть правда, что программа базы данных усердно работает над извлечением и сканированием данных позади, а затем возвращает результат (или зависает) сразу через несколько минут.Во время процесса нет обратной связи о том, сколько данных было просканировано и сколько данных предполагается просканировать.На самом деле это Опыт плохой, потому что сообщение прогресс (ClickHouse хорошо с этим справляется). Обратная связь должна быть тщательно разработана.Некоторые из моих опытов: обратная связь должна быть немедленной, предпочтительно в течение 200 мс после нажатия Enter (время физиологической реакции человека, после этого времени люди будут испытывать задержку, если обратная связь будет превышена) смысл), плавное ощущение создано обратной связью.
Обратная связь о ходе выполнения, не возвращайте детали, не возвращайте детали, которые требуют контекста для чтения (если только это не режим отладки), вот наш собственный встречный пример (спросите графа G.com/he/topic/201…
Bash
MySQL [test]> SELECT COUNT(1) AS count, SUM(account_balance) AS amount, trade_desc AS type FROM b_test WHERE member_id = 「22792279001」 AND detail_create_date >= 「2019-11-19 17:00:00」 AND detail_create_date < 「2019-11-28 17:00:00」 group by trade_desc;
ERROR 9005 (HY000): Region is unavailable
Что не так с этим случаем? Очевидно, что для пользователей Region — это внутреннее понятие TiDB, и закономерен вопрос: а что такое Region (зарыл предзнаменование впереди, не знаю, заметили ли вы)? Почему данные Select относятся к региону? Почему регион недоступен? Как я могу решить эту проблему? Предоставление этой информации пользователю бесполезно и вместо этого создает шум для пользователя. Причина этого случая заключается в том, что TiKV слишком занят, чтобы вернуть требуемые данные.Лучшая обратная связь должна быть такой: какой конкретный TiKV не может прочитать из-за каких данных (в форме, понятной пользователям, например, какая таблица и какая строка). Вышло потому, что ТиКВ слишком занят, лучше всего сообщить пользователю, почему он занят и как это решить, а если не может решить, то хотя бы выложить ссылку на FAQ (я видел софт, который напрямую вставляет URL-адрес поиска StackOverflow, LOL).
Установите несколько вех для положительной обратной связи. Например, когда серверная программа начинает нормально предоставлять услуги, она печатает Ascii Art и использует несколько цветных меток для разных уровней журнала. сделано хорошо. Как правило, создать обратную связь для интерактивных программ командной строки несложно.Очень хлопотно то, что базовое программное обеспечение обычно в значительной степени зависит от файлов конфигурации.Проблема с конфигурацией заключается в том, что цикл обратной связи от изменения конфигурации до подтверждения того, что она вступила в силу, обычно очень Обычный сценарий: измените конфигурацию — перезапустите — наблюдайте за эффектом, и обычно конфигурация сохраняется в файле конфигурации, что также приводит к крайне плохой обратной связи операции с файлом модификации, потому что пользователь не знает, будет ли эта операция вступила в силу, особенно некоторые конфигурации.Это не слишком очевидно, чтобы вступить в силу.Некоторые хорошие практики, такие как: когда программа запускается, печатать, какой файл конфигурации читается и каково содержимое файла конфигурации;дизайн командной строки функция, такая как print-default-config, напрямую выводит конфигурацию шаблона, сохраняя собственный Google пользователя.
Кроме того, для распределенных систем проблема конфигурации более сложна, потому что здесь не разница между локальной конфигурацией и глобальной конфигурацией, а распространение обновленной конфигурации, в том числе проблема скользящего перезапуска (перезапуска процесса для того, чтобы конфигурация вступает в силу сама по себе не является хорошим дизайном), если честно, у меня нет особенно хорошего решения в настоящее время.Возможная идея состоит в том, чтобы использовать распределенный глобальный центр конфигурации, такой как etcd, или (для базы данных) реализовать его через некоторые глобальные таблицы конфигурации. Но общий принцип таков: централизованное лучше, чем децентрализованное, немедленный эффект лучше, чем эффект перезапуска, унифицированное взаимодействие (способ изменения и чтения конфигурации) лучше, чем несколько способов взаимодействия. \
напиши в конце
Я, наконец, закончил писать его, но я думаю, что эта статья просто руководство.Должно быть много хороших практик, которые не были обобщены.Я также надеюсь, что друзья, у которых есть идеи, придут и обсудят со мной.Я раскрою саспенс оставил в первой главе.Почему?В первой статье наблюдаемость и интерактивность писались вместе.По сути,это модель человеческого действия из классической когнитивной психологии[3]:
Когда пользователи используют программное обеспечение, им приходится сталкиваться с двумя пробелами: один — это пробел в реализации, когда пользователь должен выяснить, как работать с программным обеспечением и «разговаривать» с ним; другой — пробел в оценке, когда пользователь должен понять результат операции. Наша миссия как дизайнеров — помочь пользователям преодолеть эти два пробела, которые соответствуют наблюдаемости и интерактивности в статьях.
Разработка приятного в использовании программного обеспечения — это искусство, и это не обязательно проще, чем разработка умного алгоритма или надежной программы, но в некотором смысле это сложнее, потому что это требует от разработчика действительно глубокого понимания и преданности делу. как к программному обеспечению, так и к программному обеспечению. Наконец, я пошлю вам сообщение от Стива Джобса:The design is not just what it looks like and feels like. The design is how it works.
Ссылка: [1]Наблюдаемость распределенной системы в моих глазах, Dongxu Huang, 2020 г. [2] Перегруженная рабочая память выбивает мозг из синхронизации | Quanta Magazine [3] The Design of Everyday Things, Дональд Норман, 1988 г.