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

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

Меня зовут Антон Маркелов, я ops-инженер компании United Traders. Мы занимаемся проектами, так или иначе связанными с инвестициями, биржами и прочими финансовыми делами. Компания мы не очень большая, около 30 инженеров разработки, масштабы соответствующие – чуть меньше сотни серверов. В ходе количественного и качественного роста нашей инфраструктуры классическое решение «держим на одном сервере и приложение, и его базу» перестало нас устраивать как в плане надежности, так и в плане быстродействия. Со стороны аналитиков возникла потребность создавать кроссбазные запросы, отделу эксплуатации надоело возиться с бэкапом и мониторингом большого количества серверов БД. Вдобавок ко всему, хранение стейта на одной машине с самим приложением сильно снижала гибкость планирования ресурсов и отказоустойчивость инфраструктуры.

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

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

«Человек-снежинка» с КДПВ бессовестно позаимствован у Максима Дорофеева.

Качество кода — тема, которая родилась вместе с программированием. Для оценки и контроля качества менеджмента предприятий применяется ISO 9000, для продуктов — ГОСТ и тот же ISO, а вот для оценки качества кода ГОСТа нет. Точного определения и стандарта для качества кода тоже нет.



Каждый разработчик понимает качество по-своему, исходя из опыта. Представления джунов и лидов различаются, и это приводит к разногласиям. Каждая команда для отдельных проектов оценивает код по-своему. Команда обновляется, разработчики уходят, тимлиды сменяются — определение качества меняется. Эту проблему попробует помочь решить Иван Ботанов (StressoID) из Tinkoff.ru — Frontend-developer, преподаватель онлайн-курса по Angular, спикер на митапах и конференциях, ведущий уроков на YouTube и, иногда, тренер команд в компаниях.

В расшифровке доклада Ивана на Frontend Conf поговорим о читаемости, нейминге, декларативности, Code style, и косвенно коснемся отношений джунов и лидов: ошибки, грабли и «сгорание» тимлидов.

Disclaimer: Подготовьтесь морально, в тексте будет много плохого кода, взятого с «особенного» сайта.

Массачусетский Технологический институт. Курс лекций #6.858. «Безопасность компьютерных систем». Николай Зельдович, Джеймс Микенс. 2014 год

Computer Systems Security — это курс о разработке и внедрении защищенных компьютерных систем. Лекции охватывают модели угроз, атаки, которые ставят под угрозу безопасность, и методы обеспечения безопасности на основе последних научных работ. Темы включают в себя безопасность операционной системы (ОС), возможности, управление потоками информации, языковую безопасность, сетевые протоколы, аппаратную защиту и безопасность в веб-приложениях.

Лекция 1: «Вступление: модели угроз» Часть 1 / Часть 2 / Часть 3
Лекция 2: «Контроль хакерских атак» Часть 1 / Часть 2 / Часть 3
Лекция 3: «Переполнение буфера: эксплойты и защита» Часть 1 / Часть 2 / Часть 3
Лекция 4: «Разделение привилегий» Часть 1 / Часть 2 / Часть 3
Лекция 5: «Откуда берутся ошибки систем безопасности» Часть 1 / Часть 2
Лекция 6: «Возможности» Часть 1 / Часть 2 / Часть 3
Лекция 7: «Песочница Native Client» Часть 1 / Часть 2 / Часть 3
Лекция 8: «Модель сетевой безопасности» Часть 1 / Часть 2 / Часть 3
Лекция 9: «Безопасность Web-приложений» Часть 1 / Часть 2 / Часть 3
Лекция 10: «Символьное выполнение» Часть 1 / Часть 2 / Часть 3
Лекция 11: «Язык программирования Ur/Web» Часть 1 / Часть 2 / Часть 3
Лекция 12: «Сетевая безопасность» Часть 1 / Часть 2 / Часть 3
Лекция 13: «Сетевые протоколы» Часть 1 / Часть 2 / Часть 3
Лекция 14: «SSL и HTTPS» Часть 1 / Часть 2 / Часть 3

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

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