Прямое продолжение замечательной “Ложной слепоты”.
Сюжет закручен, научные выкладки по прежнему есть, а персонажей и “вселенную” здорово расширили. Но первая часть лучше. Может быть из-за проблематики, что стала не такой серьезной. В первой части был инопланетный разум, полностью не похожий на земной. А здесь, проблемы “земные”. Или социопатов среди героев поуменьшилось. Или из-за новизны. Точно не знаю, но уровень восторга определено упал.
Честно говоря, этот пост пиша ради двух ссылок на краткие конспекты. Книга прочитана, но этого очевидно мало. Нужна практика, перечитывание и так далее. А рецензию на её уже и без меня много раз писали.
Краткий конспект на английском
Графические шпаргалки: раз и два
git init project-name
git add text.txt
git rm text.txt
git status
git commit -a -m "Commit description"
git push origin master
# Скачать все ветки с origin, но не мерджить их в локальный репозиторий
git fetch origin
git branch some_branch
# Начать работать с веткой some_branch (уже существующей)
git checkout -b some_branch origin/some_branch
#Просмотреть все существующие ветви
git branch -a # | grep something
git merge some_branch
#История с именами файлов и псевдографическим изображением бранчей:
git log --stat --graph
#Улучшение для log
git config --global alias.grog 'log --graph --abbrev-commit --decorate --all --format=format:"%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(dim white) - %an%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n %C(white)%s%C(reset)"'
#Изменения, сделанные в заданном коммите:
git show d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4
#Посмотреть, кем в последний раз правилась каждая строка файла:
git blame file.txt
#Откатиться к конкретному коммиту (хэш смотрим в «git log»):
git reset --hard d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4
#Попытаться обратить заданный commit (но чаще используется branch/reset + merge):
git revert d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4
#Просмотр изменений (суммарных, а не всех по очереди, как в «git log»):
git diff # подробности см в "git diff --help"
#"Упаковка" репозитория для увеличения скорости работы с ним:
git gc
#Добавляем ключ на github
ssh-keygen -t rsa -b 4096 -C "test@test.com"
vim /home/test/.ssh/id_rsa.pub
ssh -T git@github.com
Закоммитил и тут же понял, что нужно внести небольшие изменения:
# внесите изменения
git add .
git commit --amend
# следуйте подсказкам, чтобы изменить или оставить прежний комментарий
# теперь последний коммит содержит наше изменение!
Нужно изменить комментарий к последнему коммиту:
git commit --amend
# следуйте подсказкам, чтобы изменить комментарий
Закоммитил что-то в master, а оно должно быть в новой ветке:
# создайте новую ветку из текущего состояния master
git checkout -b имя-новой-ветки
# удаляем коммит из ветки master
git checkout master
git reset HEAD~ --hard
git checkout имя-новой-ветки
# ваш коммит теперь живет в новой ветке
Cлучайно закоммитил не в ту ветку:
# откатываем последний коммит, но не удаляем изменения
git reset HEAD~ --soft
git add .
git stash
# переключаемся на нужную ветку
git checkout имя-верной-ветки
git stash pop
git add .
git commit -m "тут ваш комментарий"
# теперь изменения в нужной ветке
Запускаю diff, но ничего не происходит?
git diff --staged
Вернуть fork к изначальному состоянию
git remote add upstream /url/to/original/repo
git fetch upstream
git checkout master
git reset --hard upstream/master
git push origin master --force
Сделать первый PR
git clone /url/to/fork/repo
git remote add upstream /url/to/original/repo
git checkout master
git pull upstream master
git push origin master
git checkout -b feature/add
git push -u origin feature/add
Когда у вас есть файлы, которые специфичны для данного проекта и для вашего рабочего окружения(например, логи, third-party утилита) используйте .git/info/exclude. Этот файл не коммитуется и остается только в локальном репозитории.
Когда у вас несколько проектов и везде создается что-либо, что вы не хотите коммитить(например, *.swp файлы Vim) используйте ~/.gitconfig. Вышеприведённый пример папки .idea, которая создается для каждого проекта как раз подходит сюда.
Прошло уже два года со времен прошлой статьи powershell для тестировщиков по парсингу логов. Теперь больше работаю с Linux серверами и можно переписать статью.
Основная цель - собрать наиболее часто используемые команды и “хитрые техники” для повседневной работы уитилит grep, find, sed, awk. И так, приступим.
# Поиск по pattern в file. Для архивов удобно использовать zgrep
# Ключи: r - рекурсивный поиск, E - поддержка регулярных выражений (egrep), o - выводит только совпадений, v - все кроме указанного(invert-match), H - имя файла
grep -rEovH pattern file
# Найти файлы в директория
find . -path './web*/somethin/test.log*
# Найти все файлы, без учета регистра и искать в них pattern с перенаправлением ошибок
find . -type f -iname '*.log*' 2>/dev/null -exec grep -H 'pattern' {} \;
# Найдем общие строки между двумя файлам
sort file1 file2 | uniq -d
# Найдем частоту события pattern.
# sort - сортируем (конкеретно в этом случае не обязательно)
# uniq -ci - удаляем подсчитываем и удаляем дубликаты, i - без учета регистра
# sort -rn - сортируем по числу появлений, по убыванию
grep -oh 'pattern \[.*\]' test.log* | sort | uniq -ci | sort -rn
Часто возникает необходимость найти какое-то событие, узнать номер “thread” и дальше посмотреть всю историю. В этом поможет конструкция ниже:
grep "`grep 'pattern' test.log | grep -oh "\w\{0,\}.n11"`" test.log.
# Усложним ситуацию. Нам надо найти когда для пользователей в рамках одного "thread" случилось два события. Oдин из способов это сделать:
find . -path './2017-05-*/test.log*' | while read path; do zgrep "`zgrep 'TEST_EVENT 1' $path | awk '{print $4}'`" $path | grep -H 'TEST_EVENT 1' -B 2 -A 2 | grep '"TEST_EVENT 2"'; done
Кстати, здесь используется отображение строк до совпадения и после совпадения - grep 'TEST_EVENT 1' -B 2 -A 2, а также цикл по найденным файлам - while read path; do zgrep 'pattern' $path; done
При поиске регулярных выражений по маске '(pattern1|pattern2)' grep выводит результат в двух разных строках. Решить эту проблему нам поможет Perl.
# Две строки для каждого совпадения
find . -path './test*/test.log*' -exec zgrep -H 'login/email' {} \; | grep '\[received\]' | egrep -o '(.+\.gz|\w+-\w+-\w+ \d\d:\d\d:\d\d|"email":".+@.+\.\w+")'
# Одна строка
# Ключи -n - выполнение кода, -e - задает код, -l - обработка окончаний строк
find . -path './test*/test.log*' -exec zgrep -H 'login/email' {} \; | grep '\[received\]' | perl -lne 'print /(.+\.gz|\w+-\w+-\w+ \d\d:\d\d:\d\d|"email":".+@.+\.\w+")/g'
Полезные ссылки:
Sed - потоковый текстовый редактор
# Печатать строки где есть pattern
sed -n ‘/pattern/p’ file
# Удалить все пустые строки
sed -i ‘/^$/d’ file – remove all blank lines from file
# Заменить word1 на word2, word3 на word4
sed ‘s/word1/word2/g; s/word3/word4/g’ file– replacement with multiple patterns in file
# Заменить одно значение переменной на другое
find -type f -name "test.*" -exec sed -i 's/MaxSize=[0-9][0-9][0-9]/MaxSize=384/' {} \;\
# Рекурсивная замена по всем вхождениям
find /home/user/ -type f | xargs sed -i ‘s/a.example.com/b.example.com/g’ – recursively substitute each mattern match in files located on /home/user
# Убираем из вывода все коменты и пустые строки.
cat /opt/local/etc/squid/squid.conf | sed '/ *#/d; /^ *$/d'
# Используем регулярные выражения в find. Без sed не работают
find ./_filestorage/ -regextype sed -regex ".*/[a-f0-9\-]\{36\}\.\(jpg\|JPG\|png\|PNG\|gif\|GIF\)"
Полезные ссылки:
# F - разделитель
# NF - число полей в текущей записи (number of fields)
# NR - номер текущей записи (record number)
# FNR - номер записи для текущего файла
# Печатаем первую колонку, разделитель - пробелы или табы
awk ‘{print $1}’ file
# Разделитель :
awk -F ‘:’ ‘{print $1}’ file
# Сумма всех строк для 3 колонки
awk ‘{sum+=$3} END {print sum}’ file
# Среднее для 2 колонки
awk ‘{avg+=$2}END{print avg/NR}’ file
# Вывести все после 3 строки
awk ‘NR>3’ file– print everything aftчисло полей в текущей записи the 3rd line
# Частота использования IP
awk '{ array[$2]++ } END {for (ip in array) print array[ip],ip}' access.log
Необходимо посчитать разницу между получением и отменой офера, для этого использовалась функция mktime для работы с временем.
zgrep -E "(Quotation:.+ - notification for .+ cancelled|Quotation:.+ - offer is sent to .+)" ./test/offers.log.gz | awk ' {print ($14 == "" ? $1 " " $2 " " $7 " " $12 : $1 " " $2 " " $7 " " $14) };' | awk '{gsub("-", " ", $1); gsub(/,[0-9][0-9][0-9]/, "", $2); gsub(":", " ", $2); print mktime($1 " " $2) " " $3 " " $4;}' | awk '{
if (array[$3]==""&&q==""||(array[$3]=="" && q==$2)) {array[$3]=$1;q=$2}
else if (array[$3]!="" && q==$2) {array[$3]=$1-array[$3];}
else {for (i in array) {if (array[i]!="") print q, i, array[i];}; delete array;array[$3]=$1;q=$2;}
} END{for (i in array) print q, i, array[i];}'
Полезные ссылки:
Не правда, и не ложь, не биография, но и не вымысел. Единственный достоверный факт - талант рассказчика у Джулиана Барнса.
Хроника инцидента с базой данных GitLab.com от 2017/01/31 - перевод оригинальных постов один и два.
Учить, а не рассказывать - о написании технической документации. Читать и мечтать о недостижимом идеале.
Look before you paste from a website to terminal - наглядная демонстрация вреда от копирования напрямую в терминал.
Amazon Web Services in Plain English - просто и понятно.
Big-list-of-naughty-strings - однажды пригодится.
On Uber’s Choice of Databases - разжевывание особенностей работы PostgreSQL.
Недостаточно внимательно прочитал описание и вот результат. Вместо книги о базовых сетевых протоколах прочитал руководство по настройке сети. Хорошошее руководство, надо сказать. Но некоторые главы откровенно устарели, например, про настройку Apache или собственного email сервера. Остальное же актуально и наверное еще долго им останется.
Адресная маска работает следующим образом: если бит маски включен, соответствующий ему бит адреса входит в раздел адреса сети, а если бит маски сброшен, соответствующий бит адреса входит в раздел адреса узла. Например, для комбинации адреса 172.22.12.4 и сетевой маски 255.255.255.0, в которой включено 24 бита и сброшено 8 бит, первые 24 бита адреса представляют номер сети, а последние 8 бит - адрес узла. Сочетание адреса и маски позволяет определить, что речь идет об адресе узла 4 сети 172.11.12 Указывать одновременно адрес и маску в десятичном представлении через точку не очень удобно, поэтому есть сокращенное представление. Вместо записи “сеть 172.31.26.32 с маской 255.255.255.254” можно писать просто 172.31.26.32/27. Представление имеет форма адреса/длинна префикса, где длинна префикса - число бит в разделе сети адреса. В отсутствии подобной записи существует большая вероятность, что адрес 172.31.26.32 будет интерпретирован неверно.
Новая модель маршрутизации базируется на равенстве наборов автономных систем, называемых доменами маршрутизации Домены маршрутизации обмениваются информацией маршрутизации с другими доменами при помощи протокола граничных шлюзов (Border Gateway Protocol, BGP). Каждый домен маршрутизации обрабатывает информацию, полученную от других доменов.
Для отображения таблицы маршрутизации воспользуемся командой route с ключом -n. Ключ -n предотвращает преобразование адресов IP в имена узлов, облегчая чтение результата.
Посмотреть на буфер маршрутизации можно при помощи команды route с ключом -C
/etc/host - лежит Таблица узлов
Команда ifconfig позволяет устанавливать или определять значения настройки сетевых интерфейсов.
Сетевые интерфейсы - dmesg
netstat -in Ключ -i предписывает программе netstat отображать состояние всех настроенных сетевых интерфейсов, а ключ -n - использовать при выводе числовой формат.
nslookup – это инструмент отладки, который входит в состав пакета BIND. Программа позволяет пользователю напрямую обращаться к серверу имен с запросами и получать любую информацию, хранимую в распределенной базе данных DNS. Команда nslookup помогает определить факт работоспособности сервера и корректность его настройки, а также запросить информацию, которой владеют удаленные серверы.
При следующей перезагрузке данной системы Red Hat будет запущен вебсервер. Чтобы запустить веб-сервер без перезагрузки, необходимо выполнить сценарий httpd из командной строки: /etc/init.d/httpd start
Некоторые администраторы следуют традициям, но чаще всего настройки в полном объеме хранятся в файле httpd.conf. Это предпочтительный подход, именно его мы используем в данной главе. Расположение файла httpd.conf зависит от операционной системы. В системе Solaris он хранится в каталоге /etc/apache; в системе Red Hat – в каталоге /etc/httpd/conf; а в системах Caldera – в каталоге /etc/httpd/apache/conf. Страница руководства, посвященная Apache, должна содержать сведения о том, где в данной системе хранится файл httpd.conf; в противном случае просто обратитесь к сценарию, запускающему httpd при загрузке системы. Расположение файла httpd.conf в этом файле определено переменной сценария либо аргументом ключа -f в командной строке httpd. Разумеется, есть еще один способ найти этот файл – при помощи команды find, как в следующем примере для Caldera Linux:
find / -name httpd.conf -print /etc/httpd/apache/conf/httpd.conf
Работая в системе, вы можете непосредственно наблюдать за попадающей в файл журнала информацией посредством команды tail с ключом -f:
$ tail –l 1 –f /var/log/httpd/apache/error_log
Команда tail выводит набор строк из конца файла; в данном случае – из файла /var/log/httpd/apache/error_log. Ключ -l определяет количество выводимых строк. В данном примере -l 1 предписывает tail отобразить (одну) последнюю строку файла. Ключ -f предписывает процессу tail продолжать работу, что позволяет наблюдать записи по мере их добавления в файл. Таким образом, у нас есть возможность наблюдать за файлом в реальном времени.
Серверы, действующие в качестве промежуточных звеньев между клиентами и веб-серверами, называются прокси-серверами (proxy servers, посредники). При использовании брандмауэра прямой веб-доступ часто блокируется. В этом случае пользователи подключаются к прокси-серверу по локальной сети, тогда как прокси-сервер обладает полномочиями для подключения к удаленному веб-серверу. Прокси-серверы могут хранить копии веб-страниц с удаленных веб-серверов в целях повышения производительности, сокращения объема трафика в территориальной сети и уменьшения нагрузки на популярные веб-сайты.
Сам по себе сервер Apache надежен и достаточно защищен. Наибольшей угрозой безопасности сервера является пользовательский код, исполняемый сервером – как правило, речь идет о программах CGI (Common Gateway Interface) и SSI (Server Side Includes).
Злоумышленники часто оставляют после себя файлы или сценарии, позволяющие им повторно войти в систему либо получить полномочия администратора. Используйте команду ls -a | grep ^`.` для поиска файлов с именами, начинающимися с точки (.). Злоумышленникам особенно нравятся такие имена, как .mail, .xx, … (три точки), .. (точка, точка, пробел) или же ..^G (точка, точка,
В простейшем случае брандмауэр – это фильтрующий маршрутизатор, который блокирует нежелательный трафик. Используйте возможности маршрутизации многосетевого узла под управлением Linux и функции фильтрации iptables для создания фильтрующего маршрутизатора. Ядро Linux делит трафик маршрутизатора на три категории и применяет для каждой из категорий отдельный набор правил фильтров: INPUT Входящий трафик, адресованный процессу локальной системы, должен пройти через правила фильтра INPUT, прежде чем будет принят системой. OUTPUT Исходящий трафик, источником которого является локальная система, должен пройти через правила фильтра OUTPUT, прежде чем будет отправлен. FORWARD Трафик, исходящий от внешней системы и адресованный другой внешней системе, должен пройти через правила фильтра FORWARD.
Примеры команд iptables Если собрать все описанные средства, мы получим брандмауэр, способный защитить сеть. Предположим, что у нас есть Linux-маршрутизатор, подключенный к сетевому периметру с адресом 172.16.12.254 через интерфейс eth0 и к внешней сети с адресом 192.168.6.5 через интерфейс eth1. Кроме того, предположим, что в сетевом периметре лишь два сервера – сервер sendmail и сервер Apache. Вот пример команд iptables, которые мы могли бы выполнить на этой Linux-системе с целью защиты сетевого периметра:
iptable –F INPUTiptables –F FORWARDiptables –A INPUT –i eth1 –j DROPiptables –A FORWARD –i eth1 –s 172.16.0.0/16 –j DROPiptables –A FORWARD –o eth1 –d 172.16.0.0/16 –j DROPiptables –A FORWARD –d 172.16.12.1 25 –j ACCEPTiptables –A FORWARD –d 172.16.12.6 80 –j ACCEPTiptables –A FORWARD –j DROPПервые две команды при помощи ключа -F очищают наборы правил, с которыми мы намереваемся работать. Третья команда предписывает удалять все пакеты из внешней сети, адресованные процессам Linux-маршрутизатора. Мы не хотим, чтобы к процессам маршрутизатора обращался кто-либо из внешнего мира. Следующие две команды предписывают удалять пакеты, передаваемые во внешний мир с внутреннего адреса. Если пакеты приходят через внешний интерфейс и имеют внутренний адрес, они удаляются. Точно так же, если пакеты, передаваемые через внешний интерфейс, имеют конечный адрес в локальной сети, они удаляются. Эти правила говорят, что если пакеты из внешней сети (проходящие через интерфейс eth1) некорректно используют адреса внутренней сети (172.16), кто-то пытается организовать атаку, основанную на подделке пакетов, и такие пакеты следует удалять. Следующие два правила практически идентичны. Они предписывают принимать пакеты, если пункт назначения и номер порта соответствуют конкретному серверу. Например, порт 25 – это порт SMTP, а 172.16.12.1 – адрес почтового сервера, тогда как порт 80 – это порт HTTP, а 172.16. 12.6 – адрес веб-сервера. Мы принимаем такие входящие соединения, поскольку они адресованы нужным системам. Последнее правило запрещает пропускать любой другой трафик. Эти примеры иллюстрируют мощь встроенных механизмов фильтрации Linux и содержат достаточный объем информации, чтобы вы могли начать самостоятельную работу.
Инструменты, перечисленные в каталоге и описанные в этой книге:
ifconfig - Предоставляет сведения о базовых настройках интерфейса. Полезна для поиска неверных IP-адресов, некорректных масок подсетей, а также неверных широковещательных адресов.arp - Предоставляет информацию о преобразовании адресов Ethernet/IP. Может использоваться для обнаружения систем локальной сети, при настройке которых использовался неверный IP-адрес.netstat - Предоставляет самую разнообразную информацию. Повсеместно используется для вывода подробной статистики по каждому из сетевых интерфейсов, по сетевым сокетам, а также таблицам маршрутизации.ping - Позволяет определить, доступен ли удаленный узел. ping отображает статистику по потерянным пакетам и времени доставки.nslookup - Предоставляет информацию о службе имен DNS.dig - Также предоставляет информацию о службе имен. По функциональности схожа с nslookup.traceroute - Выводит информацию о каждом из транзитных участков маршрута, по которому проходит пакет от вашей системы до удаленной.snoop - Анализирует отдельные пакеты, которыми обмениваются узлы сети. snoop – это анализатор протоколов TCP/IP, включенный в состав системы Solaris 8. Он позволяет изучать содержимое пакетов, включая заголовки, и наиболее полезен для анализа проблем, связанных с протоколами. tcpdump – инструмент с аналогичными функциями, он поставляется в системах Linux.Post Tag: booknon-fiction
Образцово-показательная обучающая книга. Авторы методично объясняют, показывают, рассказывают и приводят множество примеров. Как писать “хороший” текст, что делать, если не получается, как улучшить. Учит, как и “просто” тексту, так и специфичным - рекламному посту, личному блогу и отзыву на вакансию.
Секрет “хорошего” текста вы и сами наверняка знаете. Забота о читателе, правда и полезность. Ничего запредельного на первый взгляд, но к чтению настоятельно рекомендуется. Как минимум потому, что авторы неукоснительно выполняют свои же правила - читать одно удовольствие. Кроме того, это ещё и очень хороша оформленная книга.
Немного ссылок:
Сила информационного стиля - в правде и фактах. Добавьте к этому простую форму, энергичную подачу и понятную структуру, и у вас получится сильный текст.
Иногда люди пишут не чтобы решить чью-то задачу, а по внутреннему зову. Мы называем это графоманией. В графомании нет ничего плохого - в мире есть гораздо более страшные явления, чем слабый текст. Но чтобы текст был сильным, мы советуем даже графоманией заниматься так, чтобы она решала задачу читателя. Допустим, парня бросила девушка. Он расстроен, он в ярости и теперь хочет поделиться с кем-нибудь своей болью. Он пишет статью в социальной сети о том, какие девушки плохие. Это графомания: текст пишется не для читателя, а для писателя. Чтобы это не было графоманией, парень должен подумать о читателе. Как он может ему помочь? Какую задачу он может решить?
Не думайте, что расшаркивания и трусливая вежливость – это ваше редкое умение. Мямлить умеют все. А вот говорить честно, прямо и уважительно - единицы. Присоединяйтесь к ним.
Если не знаете, с чего начать статью, - начните с истории. История всегда привлекает внимание.
Не стесняйтесь рассказывать клиентам о тонкостях, которые есть в вашей работе. Так вы добиваетесь двух целей: показываете свои сильные стороны и помогаете клиенту увидеть ценность вашей работы.
Если кажется, что текст получается слишком сухим, придумайте для него изюминку: что-то необычное, творческое и запоминающееся. Хорошая изюминка - такая, которая работает на тему текста не хуже, чем остальные фразы. Если всю дорогу вы рассказывали, как хорошо вы преподаете английский, не следует в изюминке говорить о вашей любимой кошке или о том, как вы занимаетесь конным спортом. Расскажите что-то такое об английском языке, что вызовет улыбку.
Избегайте оценок своей работы. Вместо этого рассказывайте о результатах и приводите доказательства: ссылки, примеры, публикации, статистику. Результаты работы можно найти всегда, даже если кажется, что их не было.
Говорить правду, даже если она неудобная. Приводить факты и доказательства. Рассказывать истории и приводить примеры. Писать коротко.
Побеждайте правдой, а не словами.
Не знаете, как пишется, напишите проще.
Критиковать работу - можно, а человека - нельзя
Хорошая и полезная книга. Главы про мониторинг и инциденты буду перечитывать, и не один раз. Но есть и проблемы, как и у прошлой книги “How Google Tests Software”. Несколько глав воспринимаются как откровенная реклама - смотрите какие крутые у нас системы (ни одной из них нет в свободном доступе), как здорово мы все автоматизируем (без конкретных примеров) и т.д. А может быть мне просто завидно.
Тем не менее, книга стоящая. Кстати, теперь доступна и онлайн Site Reliability Engineering.
Notes on Google’s Site Reliability Engineering book - товарищ постарался и написал краткий конспект по главам.
The four golden signals of monitoring are latency, traffic, errors, and saturation. If you can only measure four metrics of your user-facing system, focus on these four.
Latency - the time it takes to service a request. It’s important to distinguish between the latency of successful requests and the latency of failed requests. For example, an HTTP 500 error triggered due to loss of connection to a database or other critical backend might be served very quickly; however, as an HTTP 500 error indicates a failed request, factoring 500s into your overall latency might result in misleading calculations. On the other hand, a slow error is even worse than a fast error! Therefore, it’s important to track error latency, as opposed to just filtering out errors.
Traffic - a measure of how much demand is being placed on your system, measured in a high-level system-specific metric. For a web service, this measurement is usually HTTP requests per second, perhaps broken out by the nature of the requests (e.g., static versus dynamic content). For an audio streaming system, this measurement might focus on network I/O rate or concurrent sessions. For a key-value storage system, this measurement might be transactions and retrievals per second.
Errors - the rate of requests that fail, either explicitly (e.g., HTTP 500s), implicitly (for example, an HTTP 200 success response, but coupled with the wrong content), or by policy (for example, “If you committed to one-second response times, any request over one second is an error”). Where protocol response codes are insufficient to express all failure conditions, secondary (internal) protocols may be necessary to track partial failure modes. Monitoring these cases can be drastically different: catching HTTP 500s at your load balancer can do a decent job of catching all completely failed requests, while only end-to-end system tests can detect that you’re serving the wrong content.
Saturation - how “full” your service is. A measure of your system fraction, emphasizing the resources that are most constrained (e.g., in a memory-constrained system, show memory; in an I/O-constrained system, show I/O). Note that many systems degrade in performance before they achieve 100% utilization, so having a utilization target is essential. In complex systems, saturation can be supplemented with higher-level load measurement: can your service properly handle double the traffic, handle only 10% more traffic, or handle even less traffic than it currently receives?
Formally, we can think of the troubleshooting process as an application of the hypothetico-deductive method: given a set of observations about a system and a theoretical basis for understanding system behavior, we iteratively hypothesize potential causes for the failure and try to test those hypotheses. In an idealized model such as that in Figure 12-1, we’d start with a problem report telling us that something is wrong with the system. Then we can look at the system’s telemetry and logs to understand its current state. This information, combined with our knowledge of how the system is built, how it should operate, and its failure modes, enables us to identify some possible causes.
Common Pitfalls Ineffective troubleshooting sessions are plagued by problems at the Triage, Examine, and Diagnose steps, often because of a lack of deep system understanding. The following are common pitfalls to avoid:
Fixing the first and second common pitfalls is a matter of learning the system in question and becoming experienced with the common patterns used in distributed systems. The third trap is a set of logical fallacies that can be avoided by remembering that not all failures are equally probable—as doctors are taught, “when you hear hoofbeats, think of horses not zebras.“Also remember that, all things being equal, we should prefer simpler explanations.”
A Managed Incident Now - let’s examine how this incident might have played out if it were handled using principles of incident management. It’s 2 p.m., and Mary is into her third coffee of the day. The pager’s harsh tone surprises her, and she gulps the drink down. Problem: a datacenter has stopped serving traffic. She starts to investigate. Shortly another alert fires, and the second datacenter out of five is out of order. Because this is a rapidly growing issue, she knows that she’ll benefit from the structure of her incident management framework. Mary snags Sabrina. “Can you take command?” Nodding her agreement, Sabrina quickly gets a rundown of what’s occurred thus far from Mary. She captures these details in an email that she sends to a prearranged mailing list. Sabrina recognizes that she can’t yet scope the impact of the incident, so she asks for Mary’s assessment. Mary responds, “Users have yet to be impacted; let’s just hope we don’t lose a third datacenter.” Sabrina records Mary’s response in a live incident document. When the third alert fires, Sabrina sees the alert among the debugging chatter on IRC and quickly follows up to the email thread with an update. The thread keeps VPs abreast of the high-level status without bogging them down in minutiae. Sabrina asks an external communications representative to start drafting user messaging. She then follows up with Mary to see if they should contact the developer on-call (currently Josephine). Receiving Mary’s approval, Sabrina loops in Josephine.
Best Practices for Incident Management Prioritize. Stop the bleeding, restore service, and preserve the evidence for rootcausing. Prepare. Develop and document your incident management procedures in advance, in consultation with incident participants. Trust. Give full autonomy within the assigned role to all incident participants. Introspect. Pay attention to your emotional state while responding to an incident. If you start to feel panicky or overwhelmed, solicit more support. Consider alternatives. Periodically consider your options and re-evaluate whether it still makes sense to continue what you’re doing or whether you should be taking another tack in incident response. Practice. Use the process routinely so it becomes second nature. Change it around. Were you incident commander last time? Take on a different role this time. Encourage every team member to acquire familiarity with each role.
Simple Round Robin One very simple approach to load balancing has each client send requests in roundrobin fashion to each backend task in its subset to which it can successfully connect and which isn’t in lame duck state. For many years, this was our most common approach, and it’s still used by many services. Unfortunately, while Round Robin has the advantage of being very simple and performing significantly better than just selecting backend tasks randomly, the results of this policy can be very poor. While actual numbers depend on many factors, such as varying query cost and machine diversity, we’ve found that Round Robin can result in a spread of up to 2x in CPU consumption from the least to the most loaded task. Such a spread is extremely wasteful and occurs for a number of reasons, including: • Small subsetting • Varying query costs • Machine diversity • Unpredictable performance factors
Paxos Overview: An Example Protocol Paxos operates as a sequence of proposals, which may or may not be accepted by a majority of the processes in the system. If a proposal isn’t accepted, it fails. Each proposal has a sequence number, which imposes a strict ordering on all of the operations in the system. In the first phase of the protocol, the proposer sends a sequence number to the acceptors. Each acceptor will agree to accept the proposal only if it has not yet seen a proposal with a higher sequence number. Proposers can try again with a higher sequence number if necessary. Proposers must use unique sequence numbers (drawing from disjoint sets, or incorporating their hostname into the sequence number, for instance). If a proposer receives agreement from a majority of the acceptors, it can commit the proposal by sending a commit message with a value.
First Layer: Soft Deletion; Second Layer: Backups and Their Related Recovery Methods; Overarching Layer: Replication
Polarizing time means that when a person comes into work each day, they should know if they’re doing just project work or just interrupts. Polarizing their time in this way means they get to concentrate for longer periods of time on the task at hand. They don’t get stressed out because they’re being roped into tasks that drag them away from the work they’re supposed to be doing.
If you currently assign tickets randomly to victims on your team, stop. Doing so is extremely disrespectful of your team’s time, and works completely counter to the principle of not being interruptible as much as possible. Tickets should be a full-time role, for an amount of time that’s manageable for a person. If you happen to be in the unenviable position of having more tickets than can be closed by the primary and secondary on-call engineers combined, then structure your ticket rotation to have two people handling tickets at any given time. Don’t spread the load across the entire team. People are not machines, and you’re just causing context switches that impact valuable flow time.
Минимум технических деталей, максимум жизненных советов. Как обычно у Лимончелли, будто разговариваешь с другом. Хорошая книга об организации работы - с техникой, сетями и людьми.
Три правила привилегированного доступа Томa:
Часто пользователи применяют жаргон, но делают это неправильно. Они полагают, что именно это хочет слышать системный администратор. Они стараются помочь. Будет вполне оправданно, если системный администратор ответит им на это: “Постойте, пожалуйста. Что конкретно вы пытаетесь сделать? Просто расскажите об этом без технических понятий”.
В известной комнате UNIX в Bell Labs на стене висит небольшая табличка: “Перестаньте делать то, что не работает”.
Система контроля изменений RCS
Восприятие - это то, каким люди вас видят, это мера качества. Заметность - это сколько люди вас видят, это мера количества.
Не оставляйте восприятие и заметность на волю случая. Активно участвуйте в управлении ими. При отсутствии управления они станут катастрофой. Когда мы осознаем эти принципы, мы быстро находим много способов улучшить их.
Доведение до конца - означает завершение того, что вам поручено сделать. Счастливые системные администраторы поддерживают организованность при помощи письменных или электронных записных книжек либо КПК, в которых записаны их списки дел и календари встреч.
Управление временем предполагает его разумное использование. Вместо того чтобы повышать производительность, работая больше времени, вы можете сделать больше за тоже время при помощи нескольких приемов и небольшого планирования.
И снова, планирование - это ключ к успешному управлению временем. Вы должны начинать каждый рабочий день, просматривая свой список задач, устанавливая их приоритеты и встраивая в график рабочего дня. Такое вложение пяти минут времени имеет огромную отдачу.
Когда вы нарушаете свою старую привычку, ваш мозг может попытаться начать принимать решение с нуля. В таком случае отвлеките го, заменив эти мысли установками, которые отражают ваши заранее определенные решения. Вот несколько установок, которые работали для нас.
Свободное время прячется повсюду, но, чтобы его найти, вам нужно хорошо поискать.
Эти советы связаны с просьбами и предложениями. Они особенно полезны при переговорах о зарплате, но справедливы для любых переговоров: