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

Смотрите под катом, какие темы взлетели в прошлом году в Екатеринбурге и Казани, и какие программный комитет ждет в этом

Абсолютной надежности приложения или сервиса нельзя достичь. Пользователи этого не заметят из-за сбоев посредников — сотовых сетей или провайдеров, но при этом останутся без новых функций, потому что все разработчики будут заняты поддержанием стабильности. Но можно достичь того уровня надежности, которого будет достаточно, чтобы были довольны клиенты, бизнес и инженеры с разработчиками. В этом помогает концепция Site Reliability Engineering, которую ввел Google в 2003 году. Основная ее задача — предотвратить «футбол» с багами между разработкой и эксплуатацией.



Концепция SRE содержит много «странных вещей». В SRE разработчики не только пишут код, но и следят за тем, как он работает в продакшне. Доступность и надежность приложений и сайтов начинается с измерения доступности в виде четких показателей и установки показателей надежности. Еще в SRE есть «право на ошибку» или Error Budget. Когда это «право» исчерпано, команда занимается повышением надежности. Если нет — работает над новыми функциями.

Обо всем этом расскажет Матвей Кукуй. SLI, SLO и Error Budget, источники инцидентов и их особенности, инструкция по наведению порядка в мониторинге — об этом под катом через кейсы из реальной жизни.

Если ваша компания только внедряет DevOps или инструменты CI/CD, вам может быть полезно познакомиться с самыми распространенными ошибками, чтобы не повторить их и не наступать на чужие грабли. 

Команда Mail.ru Cloud Solutions перевела статью Avoid These Common Pitfalls When Transitioning to CI/CD by Jasmine Chokshi с дополнениями.

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

• 225 заметок с выступлений
  
• 180 км пройдено
  
• 90 фотографий со львами
  
• 6 перелетов
  
• 5 городов
  
• 4 поезда
  
• 3 тренировки
  
• 2 гостиницы
  
• 1 пара носок с эмблемой Ansible.
  

Когда Facebook «лежит», люди думают, что это из-за хакеров или DDoS-атак, но это не так. Все «падения» за последние несколько лет были вызваны внутренними изменениями или поломками. Чтобы учить новых сотрудников не ломать Facebook на примерах, всем большим инцидентам дают имена, например, «Call the Cops» или «CAPSLOCK». Первый так назвали из-за того, что когда однажды соцсеть упала, в полицию Лос-Анджелеса звонили пользователи и просили его починить, а шериф в отчаянии в Твиттере просил не беспокоить их по этому поводу. Во время второго инцидента на кэш-машинах опустился и не поднялся сетевой интерфейс, и все машины перезапускали руками.

Элина Лобанова работает в Facebook последние 4 года в команде Web Foundation. Участники команды зовутся продакшн-инженерами и следят за надежностью и производительностью всего бэкенда, тушат Facebook, когда он горит, пишут мониторинг и автоматизацию, чтобы облегчить жизнь себе и другим.



В статье, основанной на докладе Элины на HighLoad++ 2019, расскажем, как продакшн-инженеры следят за бэкендом Facebook, какие инструменты используют, из-за чего возникают крупные сбои и как с ними справиться.

Привет, меня зовут Костя Крамлих, я ведущий разработчик подразделения Virtual Private Cloud в Яндекс.Облаке. Я занимаюсь виртуальной сетью, и, как можно догадаться, в этой статье расскажу об устройстве Virtual Private Cloud (VPC) в целом и виртуальной сети в частности. А ещё вы узнаете, почему мы, разработчики сервиса, ценим обратную связь от наших пользователей. Но обо всём по порядку.

Часто, когда я говорю кому-то про уязвимость, на меня смотрят как на сумасшедшего с табличкой «Покайтесь, ибо конец света близок»!

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

В интернете много справочной литературы, но иногда самыми ценными становятся самые простые советы. Команда Kubernetes aaS от Mail.ru перевела подборку из десяти хитростей и советов, которые автор статьи собрала после года работы с Kubernetes. Советы не отсортированы по важности, но думаем, что каждый найдет что-то полезное для себя.

Я уверен, где-то существует книга «Как подсидеть тимлида». Она передается из рук в руки, из команды в команду и содержит советы типа: «Тимлид никогда не уволится по своей воле, потому что это не работа, а сказка! Его нужно сломать», или «Если ваш тимлид уехал в отпуск, напишите ему, что вам нужно поговорить, когда он вернется. Пусть вместо серфинга думает, что в его отсутствие команда разбежалась», а еще «Саботируйте попытки тимлида внедрить новые полезные рабочие процессы фразой из Agile-манифеста о том, что люди и взаимодействие важнее процессов и инструментов». Иначе просто невозможно объяснить, почему все тимлиды сталкиваются с одними и теми же проблемами и страхами.

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

Цитата анонимного тимлида о том, как он обычно готовит текст:

«Написание статьи технические специалисты обычно воспринимают так: автор сформулировал тему, немного подумал, сел и выдал текст сразу на чистовик.

Естественно, в реальности все работает по-другому. Из-за этого — разрыв идеализированного шаблона, разочарование, депрессия и вообще тепловая смерть вселенной.

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

У обычного смертного нет понимания, из каких этапов состоит задача «написать статью». Точно так, как многие в общих чертах уверены, что написать картину — это всего лишь взять краски и холст, а не сделать сто экскизов и тысячу попыток.

С редактурой черновика все то же самое — я сажусь и вычитываю наискосок весь текст, пытаясь заметить «кривые моменты», и долго думаю, как сделать ровнее (устаю и бросаю)».

За 4,5 года работы редактором в блоге Netpeak я помогла специалистам компании написать и опубликовать сотни постов для корпоративного блога. Поделюсь личным опытом, как, несмотря на приступы перфекционизма, довожу черновики до публикации.

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

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

Эта статья — практическая история о том, как мы столкнулись с проблемой разделения логов, хранимых в Elasticsearch, из-за которой пришлось поменять подход к бэкапам и управлению индексами.



Всё началось вскоре после того, как было поднято production-окружение. У нас был «боевой» кластер Kubernetes, все логи из которого собирал fluentd и направлял их напрямую в индексы logstash-yyy.mm.dd…

Привет, читатель! Предлагаю тебе хотя бы на 5 минут ни на что не отвлекаясь прочитать начало статьи дабы полностью ощутить главное правило, которое поможет тебе достичь любого уровня в английском.

Когда-то задумывался над тем почему у тебя не хватает времени и сил на то чтобы уделить время чему-то новому (изучению языка, как в нашем случае). Нужно постараться, чтобы разглядеть истинную причину за всеми этими фразами: "я слишком занят", "у меня полно других дел", "я и так не высыпаюсь, где мне найти еще время?". Приготовься, потому что как только ты усвоишь главное правило изучения чего угодно, ты не только найдешь время, но и начнешь правильно использовать те инструменты, о которых мы поговорим позже. Так что отнесись к этому со всей серьезностью.

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

Самое первое и главное заблуждение — "нужен поиск, так бери эластик!". Но в действительности, если вам нужен шустрый поиск для небольшого или даже вполне себе крупного проекта, вам стоит разобраться в теме поподробней и вы откажетесь от использования именно этой системы.

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

Кстати!

• Все курсы бесплатные (вы даже сможете попробовать платные продукты бесплатно);
• 6/6 на русском языке;
• Начать обучение можно мгновенно;
• По окончании вы получите бейдж об успешном прохождении обучения.

Присоединяйтесь, подробности под катом!

Следующая серия статей

• 8 самых новых курсов Microsoft Learn
• 10 бесплатных курсов для начинающих специалистов
• 10 бесплатных курсов для продвинутых специалистов

Эта серия статей, начало 2020 года

• 5 бесплатных курсов для ИИ-инженеров
• 6 бесплатных курсов для безопасников
• 7 бесплатных курсов для специалистов по работе с данными (Data-Science и Data-Engineering)

Более ранняя серия статей, 2019 год

• 7 бесплатных курсов для разработчиков
• 5 бесплатных курсов для IT-Администраторов
• 7 бесплатных курсов для архитекторов решений
• 6 самых свежих курсов по Azure
• 10 самых популярных курсов Microsoft на русском

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

Когда проигрываешь в мультиплеере, проще всего обвинить баланс — рандом, пушка имба и далее по списку. Но где эта грань между тем, когда не хватило собственного скилла и когда у игры есть реальные проблемы?

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

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

Поэтому темой третьей встречи сообщества PHP-разработчиков в нашем офисе мы сделали производительность бэкенда и пригласили к обсуждению коллег из Авито и «Мамбы».



Читайте под катом расшифровку дискуссии, в которой мне повезло быть модератором: как устроена инфраструктура трёх компаний, как мы измеряем производительность и на какие метрики ориентируемся, какие инструменты используем, как делаем выбор между железом и оптимизацией.

А 15 февраля приходите на следующий Badoo PHP Meetup: обсудим легаси.

Прим. перев.: Две недели назад стартовала программа Bug Bounty у Kubernetes — долгожданный и важный шаг для столь масштабного Open Source-проекта. В рамках этой инициативы любой энтузиаст, обнаруживший проблему в безопасности K8s, может получить награду в объёме от 100 USD (минимальная критичность) до 10 000 USD (наивысшая критичность для компонента из ядра Kubernetes). Анонс программы был сделан сотрудниками Google, занимающимися безопасностью K8s — его перевод представлен ниже.



14 января Комитет по безопасности продукта Kubernetes (Kubernetes Product Security Committee) запустил новую программу bug bounty, в рамках которой исследователи будут получать вознаграждение за обнаруженные уязвимости в Kubernetes. Спонсором программы выступает CNCF.