Я уже рассказывал, как мы «ловим» проблемы PostgreSQL с помощью массового мониторинга логов на сотнях серверов одновременно. Но ведь кроме логов, эта СУБД предоставляет нам еще и множество инструментов для анализа ее состояния — грех ими не воспользоваться.

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


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

Сегодняшняя статья — о том, какие выводы можно сделать, наблюдая в динамике различные метрики баз PostgreSQL-сервера, и где может скрываться проблема.

Перевод статьи подготовлен специально для студентов курса «DevOps практики и инструменты».

---

Фабиан Рейнарц (Fabian Reinartz) — разработчик программного обеспечения, фанат Go и любитель решать сложные задачи. Также он мэйнтейнер Prometheus и соучредитель Kubernetes SIG instrumentation. В прошлом он был production-инженером в SoundCloud и возглавлял группу мониторинга в CoreOS. В настоящее время работает в Google.

Бартек Плотка (Bartek Plotka) — инфраструктурный инженер в Improbable. Увлекается новыми технологиями и проблемами распределенных систем. Имеет опыт низкоуровневого программирования в Intel, опыт контрибьютора в Mesos и production-опыт SRE мирового масштаба в Improbable. Занимается улучшением мира микросервисов. Три его любви: Golang, open source и волейбол.

Глядя на наш флагманский продукт SpatialOS, вы можете догадаться, что для Improbable нужна высокодинамичная облачная инфраструктура глобального масштаба с десятками кластеров Kubernetes. Мы были одними из первых, кто начал использовать систему мониторинга Prometheus. Prometheus способен отслеживать миллионы метрик в реальном времени и поставляется с мощным языком запросов, позволяющим извлекать необходимую информацию.

Простота и надежность Prometheus является одним из основных его преимуществ. Однако, пройдя определенный масштаб, мы столкнулись с несколькими недостатками. Для решения этих проблем мы разработали Thanos — проект с открытым исходным кодом, созданный компанией Improbable, для бесшовной трансформации существующих кластеров Prometheus в единую систему мониторинга с неограниченным хранилищем исторических данных. Thanos доступен на Github здесь.

Кластеризация — это такая магическая штука: она превращает большой объём неструктурированных данных в потенциально обозримый набор кластеров, анализ которых позволяет делать выводы о содержании этих данных.

Приложений у методов кластеризации огромное количество. Например, мы кластеризуем поисковые запросы для того, чтобы повышать обобщающую способность алгоритмов ранжирования: любая статистика, вычисленная по группе похожих запросов, надёжнее той же статистики, вычисленной для одного отдельного запроса. Кластеризация позволяет повышать качество на запросах с редко встречающимися формулировками. Другой понятный пример — Яндекс.Новости, которые автоматически формируют сюжеты из новостных сообщений.

В далёком 2013 году мне повезло поучаствовать в разработке очень сложного алгоритма кластеризации. Требовалось с очень высоким качеством кластеризовать сотни тысяч объектов и делать это быстро: за десятки секунд на одной машине. Первым делом нужно было построить систему оценки качества, и в этой статье я расскажу именно о ней.

Самое дурацкое занятие на свете – изменять. Оно даёт необычайно сильные эмоции, с одной стороны, а с другой – способно начисто выхолостить, опустошить, лишить друзей и даже любимой работы.

Пару историй расскажу. На истину в высшей инстанции не претендую, разумеется.

25 апреля в рамках «Дня тренинга МГУ 2020» Алексей Каптерев выступил с докладом про критическое мышление. Представляем вам часть 2 расшифровки лекции.

Часть 1 доступна по ссылке.

Привет, меня зовут Александр Васин, я бэкенд-разработчик в Едадиле. Идея этого материала началась с того, что я хотел разобрать вступительное задание (Я.Диск) в Школу бэкенд-разработки Яндекса. Я начал описывать все тонкости выбора тех или иных технологий, методику тестирования… Получался совсем не разбор, а очень подробный гайд по тому, как писать бэкенды на Python. От первоначальной идеи остались только требования к сервису, на примере которых удобно разбирать инструменты и технологии. В итоге я очнулся на сотне тысяч символов. Ровно столько потребовалось, чтобы рассмотреть всё в мельчайших подробностях. Итак, программа на следующие 100 килобайт: как строить бэкенд сервиса, начиная от выбора инструментов и заканчивая деплоем.



TL;DR: Вот репка на GitHub с приложением, а кто любит (настоящие) лонгриды — прошу под кат.

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

И чтобы не проклинать каждый день, за то, что ты тратишь свои лучшие годы на эту контору, нужно иметь решимость уйти туда, где тебя будут ценить. Проходишь пару интервью — и ты в лучшем месте. Что сложного? Мне искренне непонятно, почему многие спотыкаются на этом этапе, ведь всё не так трудно, как может показаться на первый взгляд.

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

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

В статье четыре примера. Два на C++, один на TypeScript и один на Python. Способность быстро писать относительно простые алгоритмы без багов — общая необходимость, она не зависит от специализации разработчика.

Недавно на Хабре была опубликована статья Главная причина, почему не Linux, которая наделала много шума в обсуждениях. Данная заметка — это небольшой философский ответ на ту статью, который, как я надеюсь, расставит все точки над i, причем с довольно неожиданной для многих читателей стороны.

В этой статье собраны наши лучшие приемы для более эффективного использования SSH. Из нее вы узнаете как:

• Добавить второй фактор к логину SSH
• Безопасно пользоваться agent forwarding
• Выйти из вставшей SSH сессии
• Сохранить постоянный терминал открытым
• Поделиться удаленной сессией терминала с другом (без Zoom!)

Добавление второго фактора к своему SSH

Второй фактор аутентификации к своим SSH соединениям можно добавить пятью разными способами:

1. Обновить свой OpenSSH и использовать ключ шифрования. В феврале 2020 года в OpenSSH была добавлена поддержка ключей шифрования FIDO U2F (Universal Second Factor). Это отличная новая функция, но есть нюанс: только те клиенты и серверы, которые обновились до версии OpenSSH 8.2 и выше смогут пользоваться ключами шифрования, так как февральское обновление вводит для них новые типы ключей. Командой ssh –V можно проверить клиентскую версию SSH, а серверную — командой nc [servername] 22
   

Прим. перев.: эта поучительная история Omio — европейского агрегатора путешествий — проводит читателей от базовой теории до увлекательных практических тонкостей в конфигурации Kubernetes. Знакомство с такими случаями помогает не только расширять кругозор, но и предотвращать нетривиальные проблемы.



Доводилось ли вам сталкиваться с тем, что приложение «застревало» на месте, переставало отвечать на запросы о проверке состояния (health check'и) и вы не могли понять причину такого поведения? Одно из возможных объяснений связано с лимитом квот на ресурсы CPU. О нем и пойдет речь в этой статье.

TL;DR:
Мы настоятельно рекомендуем отказаться от CPU limit'ов в Kubernetes (или отключить квоты CFS в Kubelet), если используется версия ядра Linux с ошибкой CFS-квот. В ядре имеется серьезный и хорошо известный баг, который приводит к избыточному троттлингу и задержкам.

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

В интернете размещена масса руководств по командам Git, но в этой статье работа Git рассмотрена глубже, чем просто изучение команд.

Это первая часть гайда по Git из блога Pierre de Wulf в переводе команды Mail.ru Cloud Solutions. 

Посмотрим, что происходит, когда вы выполняете git rebase и почему нужно быть внимательным. 

Это вторая и третья части гайда по Git из блога Pierre de Wulf в переводе команды Mail.ru Cloud Solutions. Первую часть можно почитать тут.

Еще в декабре мне попалась одна совершенно замечательная статья на английском, посвящённая использованию системы типов языка для более широкого класса задач, для повышения надежности приложений и простоты рефакторинга. К сожалению, в тот момент я был слишком занят написанием статей по ФП, которые крайне важно было написать, пока свежи воспоминания. Но теперь, когда с этой задачей я справился, наконец дошли руки перевести эту замечательную заметку. Оригинальный язык примеров — Хаскель, но я решил переписать их на раст, для более широкого охвата аудитории. Однако язык тут совершенно неважен, советы этой статьи я применяю в ежедневной разработке на вполне себе "приземлённых" C# и TypeScript, так что если вы просто стараетесь писать надёжный и поддерживаемый код, то, вне зависимости от языка, статья вам будет в тему.

Благодарю за вычитку и помощь в переводе Hirrolot, funkill и andreevlex

Представляем вам перевод статьи Simon Holdorf, опубликованной на сайте medium.com. В ней вы найдете ссылки на полезные репозитории, с помощью которых можно прокачать навык разработки ПО.


Фото с ресурса Unsplash. Автор: Vishnu R Nair

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

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

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

В пятницу 13 сентября 2019 года Мэтью Принс и Мишель Зэтлин, сооснователи компании Cloudflare из Сан-Франциско, занимающейся интернет-безопасностью, стояли на узком мраморном балконе, с которого открывался вид на Нью-Йоркскую фондовую биржу. Стайка директоров компании сгрудилась рядом с Принсом, готовая вести вслух обратный отсчёт. «Громче! Громче! – призывал их Принс. – Пять! Четыре! Три!..» Ровно в 9:30 основатели потянулись к знаменитому колоколу биржи, знаменующему начало торгового дня, а также – выход их 10-летней компании на биржу. Так они изменили свою жизнь и сорвали куш. В тот момент они обогатились на миллионы долларов.

Более сотни сотрудников и инвесторов, стоявших внизу на первом этаже, разразились радостными криками, а их поднятые телефоны фотографировали происходящее. Кристин Холлоуэй, сотрудник №11, подняла взгляд на балкон, сделала несколько фотографий, а потом отправила их через мессенджер своему мужу, Ли Холлоуэю, третьему сооснователю компании. Он в это время находился дома, в Калифорнии. Периодически чьё-нибудь знакомое лицо выныривало из толпы, чтобы сказать ей: «Ли должен был быть здесь».

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

• Отсутствует стандарт оформления кода
  
• Не используются автоматизированные проверки
  
• Программисты не выполняют самостоятельный анализ своего кода
  
• Огромные пул-реквесты
  
• Расплывчатые пул-реквесты
  
• Отсутствуют дедлайны для код-ревью