The Guardian — одна из крупнейших британских газет, она основана в 1821 году. За без малого 200 лет существования архив накопился изрядный. По счастью, далеко не весь он хранится на сайте — всего за какие-то последние пару десятков лет. В базе данных, которую сами англичане назвали «источником истины» для всего онлайн-контента, около 2,3 млн элементов. И в один прекрасный момент они осознали необходимость миграции с Mongo на Postgres SQL — после того, как одним жарким июльским днём в 2015 году процедуры аварийного переключения были подвергнуты суровому испытанию. Миграция заняла без малого 3 года!..

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

Главная задача коммерческих (да и некоммерческих тоже) сервисов — быть всегда доступными для пользователя. Хотя сбои случаются у всех, вопрос в том, что делает IT-команда для их минимизации. Мы перевели статью Бена Трейнора, Майка Далина, Вивек Рау и Бетси Бейер «Расчёт надёжности сервиса», в которой рассказывается, в том числе, на примере Google, почему 100% — неверный ориентир для показателя надежности, что такое «правило четырёх девяток» и как на практике математически прогнозировать допустимость крупных и мелких отключений сервиса и\или его критических компонентов — ожидаемое количество простоя, время обнаружения сбоя и время восстановления сервиса.

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

Рассуждать о том, что сайт должен быть доступен всегда — моветон и банальность, но 100% доступность, хотя и является обязательным требованием, чаще всего по-прежнему недоступный идеал. Сейчас на рынке существует масса решений, которые обещают максимальный uptime или предлагают решения для его увеличения, но их применение мало того, что не всегда помогает, в некоторых случаях даже может привести к увеличению рисков и снижению доступности проекта. В этой статье мы пройдемся по классическим ошибкам, которые с которыми мы постоянно сталкиваемся. Большинство проблем — элементарные, однако люди допускают их вновь и вновь.

В прошлых двух статьях мы рассказывали об IIoT — индустриальном интернете вещей — строили архитектуру, чтобы принимать данные от сенсоров, паяли сами сенсоры. Краеугольным камнем архитектур IIoT да и вообще любых архитектур работающих с BigData является потоковая обработка данных. В ее основе лежит концепция передачи сообщений и очередей. Стандартом работы с рассылкой сообщений сейчас стала Apache Kafka. Однако, для того, чтобы разобраться в ее преимуществах (и понять ее недостатки) было бы хорошо разобраться в основах работы систем очередей в целом, механизмах их работы, шаблонах использования и основной функциональности.

Мы нашли отличную серию статей, которая сравнивает функциональность Apache Kafka и другого (незаслуженно игнорируемого) гиганта среди систем очередей — RabbitMQ. Эту серию статей мы перевели, снабдили своими комментариями и дополнили. Хотя серия и написана в декабре 2017 года, мир систем обмена сообщениями (и особенно Apache Kafka) меняется так быстро, что уже к лету 2018-го года некоторые вещи изменились.

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

Сейчас же начнем с самого первого уровня, непосредственно “вещей”, букве T из аббревиатуры IoT. С самого устройства, организации канала связи и использования протокола MQTT. Тренду IoT уже несколько лет, но по большей части представление о нем, как о лампочке и розетке, включающейся с телефона. Но на производстве, добыче, и в различных других индустриях десятками лет используются самые разнообразные сенсоры, значения с которых собираются в производственные SCADA. Всего-то подключить поток данных к интернету, и мы получаем тот самый IoT, точнее IIoT — индустриальный интернет вещей.

За последний год мы спроектировали (и продолжаем поддерживать) несколько IIoT проектов. Возможно, вы слышали о IIoT, но, на всякий случай, мы попробуем максимально просто объяснить что это такое и почему это интересно разработчикам, архитекторам и администраторам высоконагруженных решений.

IoT — интернет вещей — подразумевает управление устройствами, предназначенными для выполнения простых бытовых задач (открыть ворота гаража, когда подъезжает машина, включить свет по датчику движения или по команде, следить за температурой в помещении), то под IIoT — индустриальным интернетом вещей — обычно имеется в виду “оцифровка” данных с производств, на основе которых можно провести экспертный анализ, часто при помощи машинного обучения.

Мониторинг — это главное, что есть у админа. Админы нужны для мониторинга, а мониторинг нужен для админов.

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

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

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

Сказать, что для Docker'а 2017 год выдался тяжёлым, было бы преуменьшением. Не могу вспомнить ни одного столь раскрученного и хорошо обеспеченного деньгами стартапа из Долины, кроме Uber'а, который бы провёл 2017 год так же невнятно, как Docker. 2017 стал тем годом, когда Docker, великолепный образчик программного обеспечения, был полностью уничтожен плохим бизнес-управлением. Эта заметка — сторонний взгляд на то, как и где Docker пошёл не туда, и как попытки что-либо исправить оказались слишком слабыми и запоздалыми.

Эта статья — вольный пересказ моего доклада на прошедшем Хайлоаде.

Я возглавляю компанию, в которой работает 75 человек, а начинали мы 10 лет назад впятером.

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

13 октября мы провели вторую конференцию сообщества Uptime. В этот раз дата проведения выпала на пятницу 13-е, поэтому основная тема — аварии, и как с ними справляться. Это первый из серии постов про доклады с прошедшей конференции.

У меня есть три страшные истории о том, как по нашей вине все сломалось, как мы это чинили, и что мы делаем теперь, чтобы это не повторилось.

Через три недели, в пятницу, 13-го, в коворкинге Deworkacy в Москве пройдет уже вторая конференция сообщества Uptime, тема которой — аварии в ИТ-инфраструктуре. Мест всего 300, участие бесплатное — под катом есть ссылка на регистрацию.

Начиная с момента появления Nginx в 2004 году, мы все задавались вопросом: когда же на nginx можно будет запускать приложения? Мы запускали PHP в php-fpm и на апаче, запускали Python через uWSGI, иногда жили с Apache, а если нам нужны были разные версии PHP — жили с зоопарком из FPM-ов.



Только что на конференции NginxConf в Портленде Nginx, Inc. объявил о запуске Nginx Application Platform. ITSumma тестировала один из его компонентов, собственно сам Application Server под названием Nginx Unit с закрытой версии. В этом посте мы расскажем о том, как выглядит Nginx Unit, и как на нем запускать приложения.

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



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

На конференции Monitorama Пит Чеслок из Threat Stack провел параллель между историей строительства шведского корабля «Васа» и провальными проектами по разработке. Делимся с вами отрывком его выступления.



Корабль «Васа» должен был стать главным боевым кораблем шведского флота, но затонул с порывом ветра при первом же выходе из гавани в 1628 году, 53 члена экипажа погибли. Выживший капитан был немедленно отправлен в тюрьму: на допросе он клялся, что пушки были надежно закреплены, и экипаж был трезв. После расследования никто не был наказан или признан виновным, и инцидент был классифицирован как «Воля Божья». Почему затонул корабль и причем тут управление проектами?

Второй Uptime day (первый прошёл в апреле) мы решили посвятить фатальным происшествиям в IT-инфраструктуре — такие рано или поздно случаются в жизни у каждого. Выбрать дату было несложно — встречайте «Uptime day: Пятница, 13-е» (кстати, в этом году осталась только одна такая пятница).



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

Мы уже немного рассказывали о том, как устраиваем квесты для участников ИТ-конференций. Сегодня запускаем онлайн-игру для админов (идея квеста была переработана и дополнена) — the Maze. Под катом — ее история. Включайтесь!

Ситуация: у вас парк Linux-серверов, куда вы регулярно заходите по SSH. Двухфакторная аутентификация для SSH по какому-либо железному ключу или Google Authenticator настраивается, может быть, и просто, но далеко не всегда удобно эту настройку производить на каждом сервере, их может быть слишком много, или просто страшно перезапускать sshd :)

Выходом из этой ситуации может быть промежуточный аутентификационный сервер. Мы уже писали про выкладку нашего решения (Isolate) в опенсорс, в этой же статье — инструкция по настройке аутентификационного сервера с двухфакторной аутентификацией по одноразовым ключам через Google Authenticator.

У нас беспокойная работа — с сайтами, которые мы поддерживаем, постоянно что-то происходит, и на любую аварию мы должны среагировать за 15 минут — все это в режиме 24/7, семь дней в неделю. Задачи для админов невозможно запланировать — сложно представить себе такой план на неделю: случится 25 аварий, и мы их устраним одну за другой. О том, как мы пытаемся с этим жить, я и хочу рассказать.

В ноябре 2016-го мы задумались о том, как стать необычным партнером отраслевой конференции — чтобы запомниться участникам, но при этом не ограничиваться стендом и раздачей фирменных стикеров и другой сувенирки, ради которых участники обходят выставочную зону на любом мероприятии. Для Highload 2016 мы тогда придумали небольшой интеллектуальный квест — поставили прямо на стенде компьютер, на котором нужно было починить сломанный сервер. Всем понравилось, а мы стали думать дальше. На афтепати Codefest в Новосибирске в апреле мы придумали и провели гикнайт Deadliner — это была альтернативная тусовка, где у участников была важная миссия: команды спасали падающий самолет. Сегодня мы предлагаем спасти его хабрасообществу.