Здравствуйте, коллеги!

Хочу поделиться поделиться своим решением проблемы, которая указана в заголовке. Написанием статьи вдохновился от коллеги brnovk, который не поленился и предложил частичное (для меня) решение проблемы. Я сделал свой «костыль», который помог мне. Делюсь с вами.

Рисунок 1 — Плата устройства

Большой опыт работы в сфере промышленной автоматизации и АСУТП, казалось бы, должен способствовать тому, что со временем уже много всего видел и много всего знаешь. Но не тут-то было. Оказывается, иногда могут возникать задачи и проекты, которые трудно реализовать стандартными средствами. Так под один крупный проект по мониторингу и управлению в «облаке» одного небезызвестного завода N требовалось найти подходящее железо. Однако оказалось, что в России по требованиям помехозащищенности устройства и открытости системы ничего подходящего не существует. Попытка заказать идеально подходящее нам устройство из-за рубежа провалилась, поскольку на территорию нашей страны оборудование с пометкой «IoT» весьма трудно ввести в промышленных масштабах. Другие же поставщики не устроили сроками доставки в 12 недель при небольших объемах и ценой. Поэтому в голове родилась и плотно осела мысль о создании своего устройства. Причем такого, чтобы оно было универсальным и подходило не только конкретно под этот один проект, а под множество других. В итоге от момента зарождения идеи, подбора поставщиков и корпуса, разработки платы, её отладки и тестирования, написания инструкций и технической документации прошло весьма много времени. Но зато теперь я держу с легким трепетом в руках полностью законченное и рабочее устройство, и могу заявлять, что мы это сделали!

Запуск Raspberry Pi с полной поддержкой графики на microSD, навсегда остающейся в режиме read-only после установки системы. Отсутствие какой-либо записи данных на флэш-память повышает надёжность устройства, приближая его к промышленному классу изделий. Пошаговая инструкция. Небольшой театр инженерного абсурда для развлечения аудитории.

Мне понадобилось сетевое устройство с открытым кодом и выходом HDMI, и я решил попробовать Малиновый Прог. Да, я именно так предлагаю переводить Pi: Прог. Понятное дело, даже одноплатнику нужна операционка. И вот, захожу я на официальный сайт, ожидая встретить там подробное руководство по созданию суровой, неломаемой Вещи à la turnkey box. Но народ, как ни в чём не бывало, устанавливает Ubuntu (т.е. Raspbian Jessie) прямо на microSD, размещая и swap там же. Как обычный десктоп, face palm.

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

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

Идея статьи родилась спонтанно из дискуссии в комментариях к статье «Кое-что об inode».



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

Поэтому делюсь нашим опытом, может кому и пригодится.

Многие сетевые приложения состоят из веб-сервера, обрабатывающего трафик в реальном времени, и дополнительного обработчика, запускаемого в фоне асинхронно. Есть множество отличных советов по проверке состояния трафика да и сообщество не перестает разрабатывать инструменты вроде Prometheus, которые помогают в оценке. Но обработчики порой не менее – а то и более – важны. Им также нужны внимание и оценка, однако руководства по тому, как осуществлять это, избегая распространенных подводных камней, мало.

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

Мы увидим, как использовать метрики таким образом, чтобы обеспечить точную оценку, а в заключении покажем эталонную реализацию prometheus-client-tracer с открытым исходным кодом, который и вы можете применить в своих приложениях.

Однажды мой знакомый, который на тот момент администрировал некое веб-приложение на сервере под управлением GNU/Linux, пожаловался на одного вредного администратора сервера. Тот ни в какую не хотел устанавливать htop, несмотря на все просьбы.

Я немного удивился и поинтересовался, в чём причина такого странного поведения. Если упростить, то дальнейший наш диалог получился вот таким:

Введение

На данный момент, на рынке представлен большой ассортимент одноплатников на любой вкус по приемлемой цене.

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

Вы под давлением коллег или сокурсников из более успевающих групп решились на отчаянный шаг, способный разделить вашу жизнь на период "до" и "после" (прошли vimtutor), и теперь не знаете что делать с вашими новообретёнными способностями? А может вы всё ещё сидите в какой-нибудь IDE и в ус не дуете зачем вам "эти ваши программистские блокноты" и "какой-то там Vim"? Тогда присаживайтесь поудобнее и налейте себе лимонад, сейчас я вам всё по полочкам разложу.

Мои предыдущие посты об использовании Vim (1, 2) читатели приняли хорошо, и пришло время обновления. В Vim 8 появилось много очень нужной функциональности, а новые сайты сообществ вроде VimAwesome облегчили поиск и выбор плагинов. В последнее время я много работаю с Vim и организовал рабочий процесс исходя из максимальной эффективности, вот снимок моей текущей работы.

Вкратце:

• FZF и FZF.vim — для поиска файлов.
• ack.vim и ag — для поиска файлов.
• Vim + tmux — ключ к победе.
• Благодаря асинхронности ALE — это новый Syntastic.
• …И многое другое. Об этом ниже.

Привет, Хабр!

Меня зовут Максим Пономаренко и я — разработчик в Спортмастере. Имею 10-летний опыт работы в IT-сфере. Начинал карьеру в в области ручного тестирования, затем переключился на разработку баз данных. Последние 4 года, аккумулируя знания, полученные в тестировании и разработке, занимаюсь автоматизацией тестирования на уровне СУБД.

В команде Спортмастера я состою чуть более года и на одном из крупных проектов занимаюсь разработкой автоматизированного тестирования. В апреле мы с ребятами из Sportmaster Lab выступали на конференции в Краснодаре, мой доклад назывался «Unit-тесты в СУБД», и сейчас хочу поделиться им с вами. Текста будет много, поэтому я решил разбить доклад на два поста. В первом мы поговорим об автотестах и тестировании в общем, а во втором я подробнее остановлюсь на нашей системе unit-тестирования и результатах ее применения.



Вначале немного скучной теории. Что такое автоматическое тестирование? Это тестирование, которое проводится программными средствами, и в современном IT оно все чаще и чаще используется при разработке ПО. Связано это с тем, что компании растут, растут их информационные системы и соответственно растет и количество функционала, которое надо тестировать. Проводить ручное тестирование становится всё накладнее и накладнее.

AntipovSN and MihhaCF

Часть вторая, в которой Атосу все норм, а вот Графу де ля Фер чего-то не хватает

UPD Часть первая здесь
UPD Часть третья здесь

Вступление от авторов:

Добрый день! Сегодня мы продолжаем цикл статей, посвященный скорингу и использованию в оном теории графов. С первой статьей Вы можете ознакомиться здесь.

Все шуточные аллегории, вставки и прочее призваны немного разгрузить повествование и не позволить ему свалиться в нудную лекцию. Всем, кому не зайдет наш юмор, заранее приносим извинения

Цель данной статьи: не более, чем за 30 минут, описать основные способы хранения данных о графах и описать правила и принципы построения нашей модели для скоринга заемщика.

Термины и определения:

• Хеш-таблица — это структура данных, реализующая интерфейс ассоциативного массива, она позволяет хранить пары (ключ, значение) и выполнять три операции: операцию добавления новой пары, операцию поиска и операцию удаления пары по ключу. Поиск по хеш-таблице, в среднем, осуществляется за время О(1).

Аудиторы, нанятые ПАО «Король» для оценки кредитоспособности НПАО «Один за всех», столкнулись с некоторыми проблемами. С одной стороны, описать схему взаимодействия 10-15 компаний и провести первичную оценку взаимодействия между компаниями очень просто, достаточно иметь под рукой лист бумаги и ручку. Но, что делать, если у вас имеется информация о взаимодействии десятков или сотен тысяч компаний? Например, если Вам нужно описать взаимодействия Арамиса со всеми его пассиями или Д’артаньяна со всеми, с кем он дрался?

Перед каждым сервисом, генерирующим хотя бы 1 Мбит/сек трафика в интернете возникает вопрос: «Как? по TCP или по UDP?» В прикладных областях, в том числе и платформах доставки уже сложились предпочтения и традиции принятия подобных решений.

По идее, если бы, к примеру, однажды один ленивый разработчик не попробовал развернуть свой ML на Python (потому что только его и знал), мир скорее всего никогда не проникся бы такой любовью к презренному «супер-джава-кодерами» языку. А сегодня слабости этого языка в прошлом контексте применения безоговорочно обеспечивают ему первенство в развертывании и запуске многочисленных майнерских А/Б.

Сравнивать можно многое: ARM с Intel, iOS и Android, а Mortal Kombat с Injustice. И нарваться на космический холивар, поэтому вернемся к теме доставки огромных объемов разноформатного контента.

Десять лет назад все были абсолютно уверены, UDP — это что-то про негарантированную доставку. Если нужен надежный протокол — это TCP. И вопреки традициям в этой статье мы будем сравнивать такие, кажущиеся несравнимыми вещи, как TCP и UDP.


Осторожно, под катом 99 иллюстраций и схем и все важные.

Выбор CEPH. Часть 1

У нас было пять стоек, десять оптических свичей, настроенный BGP, пару десятков SSD и куча SAS дисков всех цветов и размеров, а ещё proxmox и желание засунуть всю статику в собственное S3 хранилище. Не то чтобы это всё было нужно для виртуализации, но раз начал использовать opensource — то иди в своём увлечении до конца. Единственное, что меня беспокоило — это BGP. В мире нет никого более беспомощного, безответственного и безнравственного, чем внутренняя маршртутизация по BGP. И я знал, что довольно скоро мы в это окунёмся.

Задача стояла банальная — имелся CEPH, работал не очень хорошо. Надо было сделать "хорошо".
Доставшийся мне кластер был разнородным, настроенным на скорую руку и практически не тюнингованным. Он состоял из двух групп разных нод, с одной общей сеткой выполняющей роль как cluster так и public network. Ноды были набиты четырьмя типами дисков — два типа SSD, собранными в два отдельных placement rule и два типа HDD разного размера, собранными в третью группу. Проблема с разными размерами была решена разными весами OSD.

Саму настройку разделили на две части — тюнинг операционной системы и тюнинг самого CEPH и его настроек.

Предыдущий цикл был посвящен изоляции и многоверсионности PostgreSQL, а сегодня мы начинаем новый — о механизме журналирования (write-ahead logging). Напомню, что материал основан на учебных курсах по администрированию, которые делаем мы с Павлом pluzanov, но не повторяет их дословно и предназначен для вдумчивого чтения и самостоятельного экспериментирования.

Этот цикл будет состоять из четырех частей:

• Буферный кеш (эта статья);
• Журнал предзаписи — как устроен и как используется при восстановлении;
• Контрольная точка и фоновая запись — зачем нужны и как настраиваются;
• Настройка журнала — уровни и решаемые задачи, надежность и производительность.

Читайте и другие серии.

Индексы:

1. Механизм индексирования;
2. Интерфейс метода доступа, классы и семейства операторов;
3. Hash;
4. B-tree;
5. GiST;
6. SP-GiST;
7. GIN;
8. RUM;
9. BRIN;
10. Bloom.

Изоляция и многоверсионность:

1. Изоляция, как ее понимают стандарт и PostgreSQL;
2. Слои, файлы, страницы — что творится на физическом уровне;
3. Версии строк, виртуальные и вложенные транзакции;
4. Снимки данных и видимость версий строк, горизонт событий;
5. Внутристраничная очистка и HOT-обновления;
6. Обычная очистка (vacuum);
7. Автоматическая очистка (autovacuum);
8. Переполнение счетчика транзакций и заморозка.

Блокировки:

1. Блокировки отношений;
2. Блокировки строк;
3. Блокировки других объектов и предикатные блокировки;
4. Блокировки в оперативной памяти.

Даже поверхностное знание программы Wireshark и её фильтров на порядок сэкономит время при устранении проблем сетевого или прикладного уровня. Wireshark полезен для многих задач в работе сетевого инженера, специалиста по безопасности или системного администратора. Вот несколько примеров использования:

Устранение неполадок сетевого подключения

• Визуальное отображение потери пакетов
• Анализ ретрансляции TCP
• График по пакетам с большой задержкой ответа

Исследование сессий прикладного уровня (даже при шифровании с помощью SSL/TLS, см. ниже)

• Полный просмотр HTTP-сессий, включая все заголовки и данные для запросов и ответов
• Просмотр сеансов Telnet, просмотр паролей, введённых команд и ответов
• Просмотр трафика SMTP и POP3, чтение писем

Как-то давно понадобился мне хаб, желательно с большим количеством портов и c достаточно удобной формой, пригодной для встраивания вместо флоппи-дисковода в отсек 3,5''. Беглый просмотр барахолки подкинул модель D-link DUB-H7, да еще и в комбинации «2 по цене 1». Внешний осмотр ничего особенного не дал, хаб как хаб, сделан добротно, капитальный «принтерный» USB AM-BM на оборотной стороне и 3 А блок питания. Как всегда первым делом разобрал, порадовался малому количеству пустых мест вместо элементов вкупе с качественной пайкой и успокоился. Правда на всякий случай зашел в интернет посмотреть, а что это за хаб и есть ли интересные проекты с его участием. Проектов не оказалось, отзывы пользователей 50/50, в общем, никакой динамики. Хаб на протяжении 5-7 лет довольно сносно работал и выполнял свою задачу, потом плавно переместился в коробку для электронного хлама и вполне возможно сгинул бы в итоге вместе с безызвестными переходниками, адаптерами и т. п. Но произошло у меня в жизни событие, которое заставило-таки меня покопаться в мешках со старым барахлом, найти этот, как оказалось уникальный D-link, и стряхнув пыль извлечь его на божий свет. Если интересно послушать зачем — добро пожаловать под cut.

От загрузчика к ядру

Если вы читали предыдущие статьи, то знаете о моём новом увлечении низкоуровневым программированием. Я написал несколько статей о программировании на ассемблере для x86_64 Linux и в то же время начал погружаться в исходный код ядра Linux.

Мне очень интересно разобраться, как работают низкоуровневые штуки: как программы запускаются на моём компьютере, как они расположены в памяти, как ядро управляет процессами и памятью, как работает сетевой стек на низком уровне и многое другое. Итак, я решил написать еще одну серию статей о ядре Linux для архитектуры x86_64.

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

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



То, что доклад на эту тему был признан лучшим на конференции для тимлидов и о тимлидах, показывает, насколько действительно часто встречается такая ситуация. Но надо признать, конечно, что Евгений Кот (bunopus) заработал это «признание» еще и великолепным перформансом. С удовольствием делимся с вами его записью.

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

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

• Билл Любанович «Простой Python. Современный стиль программирования»
• Дэн Бейдер «Чистый Python. Тонкости программирования для профи»
• Бретт Слаткин «Секреты Python: 59 рекомендаций по написанию эффективного кода»

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

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

Всем привет. Как вы, возможно, знаете, раньше я все больше писал и рассказывал про хранилища, Vertica, хранилища больших данных и прочие аналитические вещи. Сейчас в область моей ответственности упали и все остальные базы, не только аналитические, но и OLTP (PostgreSQL), и NOSQL (MongoDB, Redis, Tarantool).

Эта ситуация позволила мне взглянуть на организацию, имеющую несколько баз данных, как на организацию, имеющую одну распределенную гетерогенную (разнородную) базу. Единую распределенную гетерогенную базу, состоящую из кучи PostgreSQL, Redis-ов и Монг… И, возможно, из одной-двух баз Vertica.

Работа этой единой распределенной базы порождает кучу интересных задач. Прежде всего, с точки зрения бизнеса важно, чтобы с данными, движущимися по такой базе, все было нормально. Я специально не использую здесь термин целостность, consistency, т.к. термин это сложный, и в разных нюансах рассмотрения СУБД (ACID и CAP теорема) он имеет разный смысл.

Ситуация с распределенной базой обостряется, если компания пытается перейти на микросервисную архитектуру. Под катом я рассказываю, как обеспечить целостность данных в микросервисной архитектуре без распределенных транзакций и жесткой связности. (А в самом конце объясняю, почему выбрал для статьи такую иллюстрацию).