Instagram рассказал о том как они уменьшили потребление памяти своих серверных приложений на 10% просто напросто выключив GC (Python)

https://engineering.instagram.com/dismissing-python-garbage-collection-at-instagram-4dca40b29172
#python #instagram #gc

На волне всеобщего увлечения devops'изацией, в куче компаний решили что админы не нужны, и управлением серверами могут заниматься сами разработчики. Могут, но неплохо бы думать научиться, чтобы небыло как с GitLab: один разработчик случайно удаляет продакшн базу данных, перепутав сервера. И тут выясняется, что бэкапы есть, но восстановить из них ничего нельзя. В общем поучительная история. https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub

К сожалению у меня последние пару недель не было возможности постить новости. Но на эти выходные я поехал на FOSDEM и возродил старый канал с трансляцией коротких конспектов докладов, которые я посещаю. К сожалению их будет не очень много, но может будет интересно:
https://t.me/linuxconnotes

Pinterest выложил в OpenSource свою системы репликации и кластеризации для RocksDB под названием Rocksplicator. Она написана на C++, позволяет делать асинхронную master-slave репликацию, оптимизирована для низких задержек.

В заметке также описана архитектура решения, так что если вам не интересен RocksDB, все равно стоит почитать.

https://medium.com/@Pinterest_Engineering/open-sourcing-rocksplicator-a-real-time-rocksdb-data-replicator-558cd3847a9d

#rocksdb #replication #pinterest #highavailability

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

Такое, например, недавно произошло с CloudFlare - из-за ошибки в реализации парсера, используемого для HTTP Rewrite и Server-Side Excludes в течении последних нескольких месяцев возможны были редкие утечки кусков памяти веб-сервра, которые содержали например HTTP заголовки ответов от других клиентов. Проблему уже успели окрестить CloudBleed.

Подробности в блоге самих CloudFlare: https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/

#security #bugs #cloudflare #cloudbleed

Если вы еще не слышали про коллизию sha-1: Google и национальный институт исследований математики и компьютерных наук в Нидерландах (CWI) научились делать взаимные правки двух произвольных файлов так, чтобы в резульате их SHA1 сумма совпадала. Исследования заняли два года.

Что это значит для всех нас? Пора уже закопать стюардессу и перейти хотя бы на SHA-256 или SHA-3.

Подробности в блоге: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

#google #sha1 #security

Cloudflare опубликовал предварительный отчет о влиянии случившегося Cloudbleed на приватные данные пользователей.

Подробности в официальном блоге: https://blog.cloudflare.com/quantifying-the-impact-of-cloudbleed/

#cloudflare #cloudbleed #security

Amazon опубликовал отчет о случившемся 28-ого февраля с S3 в регионе US-EAST-1.

tldr: ошибка в команде и вместо небольшого количества серверов грохнули несколько больше. На этих серверах физически крутились системы отвечающие за чуть больше чем все общение с AWS и распределение новых объектов. Понадобилось делать полный перезапуск пострадавших сервисов, что и вызвало outage.

Подробности: https://aws.amazon.com/message/41926/

#amazon #fuckup #outage #s3

GitHub поменял свои условия пользования сервисов (Terms of Service).

Некоторые люди даже удалили свои проекты с GitHub, так как посчитали что новые условия не совместимы с GPL и некоторыми другими свободными лицензиями. При этом есть и альтернативный анализ (более рациональный) из которого следует что в общем ничего не изменилось, просто GitHub себя обезопасил от судебных приследований со стороны неадекватных пользователей.

Именно на такой анализ я и хотел бы дать ссылку: https://www.earth.li/~noodles/blog/2017/03/github-tos-change.html

#github #tos #licenses

История о очень нетривиальном баге, встретившемся и его отладке в Production.

Завязка истории проста - система, живущая в докере на множестве машин периодически теряла пакеты. В процессе исследования, автору статьи пришлось понять как работает сеть в докере и вспомнить некоторые относительно низкоуровневые способы отладки.

https://medium.com/@loginoff/debugging-a-docker-heisenbug-in-production-586ccb265f7c#.1raew6ciy

#docker #troubleshooting #network

Сравнение лицензий для кода с юридической точки зрения. Сравнение сделано по двум критерям - простота использования в коммерческих продуктах (Pain) и четкость формулировок (Confusion) с краткими комментариями по каждой.

https://writing.kemitchell.com/2017/03/29/OSS-Business-Perception-Report.html

#Licenses #opensource

Опубликованы видеозаписи с GCI17 (GopherCon India 2017).

Они в основном про написание кода на Го и сам Го, но есть и более общие, например Day 2 - 5. Matthew Campbell - Building Distributed Timeseries database (https://www.youtube.com/watch?v=KqXA6L-EAVA)

Полный список можно найти на канале:
https://www.youtube.com/channel/UCsFcsHYBdNA1mIPXKSND1zw/videos

#gophercon #gci17 #videos

Опубликованы видеозаписи c SRECon 2017 Americas, проходившей 13-ого марта в Сан-Франциско.

Для тех кто не в курсе - SRECon посвящена автоматизации, мониторингу, методологиям DevOps и SRE. Хоть она и молодая, но уже завоевала себе славу одной из немногих конференций куда стоит съзедить, в первую очередь из-за уровня своих докладов.

https://www.usenix.org/conference/srecon17americas/program

#videos #srecon #srecon2k17

Spotify рассказал про то, как устроен их DNS. Данный доклад отчасти повторяет то, что они рассказали на SRECon 2017 в San Francisco.

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

https://labs.spotify.com/2017/03/31/spotifys-lovehate-relationship-with-dns/
#dns #spotify

И второй пример доклада с SRECon - от Google, о том как они делают мониторинг и оповещения по Time Series данным

https://www.usenix.org/conference/srecon17americas/program/presentation/wilkinson
#srecon2k17 #srecon #monitoring #timeseries #alerting

Сегодня был выложен Graphite 1.0.0. С момента последнего minor релиза прошло более полутора лет разработки.

Главное в релизе:
1. Добавлено 30 новых математических функций
2. Новые форматы отображения данных (pdf, dygraph, rickshaw)
3. Новые параметры (pieLablels, hideXAxis, и т.п.)
4. Огромное количество исправленных ошибок
5. Переписан механизм кластеризации - теперь он использует пул воркеров и соединений
6. graphite-web поддерживает плагины для других хранилищ
7. carbon теперь поддерживает плагины для протоколов и хэширования.

Полный список нововведений и исправлений можно прочитать в документации:
https://graphite.readthedocs.io/en/latest/releases/1_0_0.html

#graphite

*Минутка саморекламы*

Сегодня вечером я буду рассказывать про то как мы готовим Graphite в Booking.com на посиделках hangops_ru. Посиделки состоятся в 9 вечера по московскому времени, участие бесплатное, все происходит в zoom конференции через интернет. Каверзные вопросы приветствуются!

Ссылка на событие в facebook: https://www.facebook.com/events/411422042554414/?ti=cl

#graphite

*Вторая минутка саморекламы*

Встреча начнется через 5 минут.
Напомню ссылку: https://t.me/devops_news/113

#graphite

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

https://honeycomb.io/blog/2017/04/lies-my-parents-told-me-about-logs/
#logging #lies

Мир полон лжи. Что делать, если то к чему ты привык оказалось неправдой? Автор данной статьи присмотрелся внимательно к такой казалось бы простой и очевидной вещи как CPU Utilization и понял что она на самом деле не соответствует действительности в современных системах.

Почему это так и что с этим делать - читайте в статье Brendan Gregg'а:
http://www.brendangregg.com/blog/2017-05-09/cpu-utilization-is-wrong.html

#performance #metrics #cpu