Рубрика «Блог компании QIWI»

Привет! Меня зовут Пётр, я менеджер по отказоустойчивости в QIWI. В этом посте мы поговорим про выбор новых классов продуктов. Как-то раз мы с одним разработчиком из другой компании стали обсуждать, почему бы не выбрать для работы какую-то распределенную СУБД, поддерживающую SQL? Из этой дискуссии родился мой доклад для нашей QIWI Server Party. Представляю вам его текстовую версию.

Читать полностью »
Заставим производителей раскрыть дату смерти электроники - 1

Наш анализ 14 популярных потребительских устройств показал, что они могут прекратить работать через 3-4 года из-за незаменяемых аккумуляторов. В этой статье мы расскажем, как заставить отрасль технологий проектировать продукты, способные проработать дольше и наносить меньше ущерба окружающей среде.

Если у вас есть наушники Apple AirPods, то они умрут, и, наверно, раньше, чем вы могли бы предположить.

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

Разве технологии обязательно должны так работать? Нет, просто так технологические компании могут заработать на вас больше денег.
Читать полностью »

Чего вам не говорили про сокеты - 1

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

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

Я создал принтер чеков для issues в GitHub - 1

У меня есть много хобби-проектов в GitHub. Некоторые из них довольно популярны, поэтому к ним время от времени постят issues. Проблема в том, что они теряются в куче моих электронных писем или я забываю пройтись по своим репозиториям и добавить новые пункты в список дел.

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

Спойлер: у меня получилось!
Читать полностью »

Как-то я получил от своего отца (мы вместе с ним работаем на одного клиента) сообщение с приложенной фотографией.

Загадочное дело о Raspberry Pi в шкафу для сетевого оборудования - 1

Сообщение от отца

Я попросил его отключить устройство, положить в безопасное место, сфотографировать со всех сторон и сделать образ SD-карты (потому что в основном я работаю удалённо). Я работал над многими проектами с Raspberry Pi и был уверен, что разберусь в назначении этого устройства.

В тот момент ещё никто не думал, что оно может быть зловредным, скорее, все думали, что это экспериментирует кто-то из сотрудников клиента.
Читать полностью »

… простите, мигрировали куда? Туда!

CockroachDB — PostgreSQL-совместимая (по SQL-синтаксису DML) распределенная СУБД с открытым кодом (ну, почти). Ее название символизирует, что она, как таракан, выживает в любых экстремальных ситуациях. Лично мне крайне импонирует такая СУБД с привычным SQL-интерфейсом, настройка которой занимает 5 минут, которая хранит данные — как Kafka — на нескольких узлах в нескольких ЦОДах сразу, имеет настраиваемый replication factor на уровне конкретных таблиц, легко переживает потерю как одного узла, так и целого ЦОДа, использует для этого механизм распределенного консенсуса Raft и при этом еще и имеет строгую консистентность и уровень изоляции serializable. Разработчики CockroachDB — выходцы из компании Google, которые решили коммерциализировать архитектуру распределенной СУБД Spanner.

Как мы мигрировали критичную БД с Oracle в CockroachDB - 1

Недостатки тоже есть, не переживайте, но про них лучше в другой раз :)

Почему именно CockroachDB?

Среди распределенных SQL-СУБД есть альтернативы в виде Yugabyte и TiDB, и с прошлого месяца YDB. Вопрос «Почему?» связан в первую очередь с тем, зачем вообще нужна БД. Как мне кажется, БД нужна для того, чтобы надежно хранить данные и доставать их через стандартный язык SQL, а удобство ее использования — приятный, но вторичный фактор. Тут надо заметить, что я почти 9 лет проработал в техподдержке Oracle, и видел достаточно случаев порчи БД, как из-за дисковых сбоев и ошибок администраторов, так и из-за багов в приложении и даже в коде самой СУБД.

Ключевыми критериями выбора были:
Читать полностью »

Машина Тьюринга в Doom - 1

DOOM (игра 1993 года для DOS) полон по Тьюрингу. Это значит, что можно запустить DOOM в DOOM. В статье приводятся подробности реализации.

Предисловие

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

Что такое полнота по Тьюрингу?

Итак, какую-то видеоигру можно назвать универсальной, полной по Тьюрингу или программируемой. Что это означает? По сути, это значит, что в этой игре можно реализовать компьютер. Но тут есть свои тонкости: если для этого игроку придётся делать слишком много, то это будет уже не так интересно.
Читать полностью »

В кодинге главное — не кодинг

Как вы думаете, что такое программирование?

Написание кода?

Написание хорошего кода?

Нет.

Это только часть истины.

Программирование — это не про кодинг. Программирование — это о решении задач при помощи кодинга.

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

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

Это самое важное, что я бы хотел знать, когда учился программированию.
Читать полностью »

На дворе 2020 год и фоновым шумом вы уже привыкли слышать: «Кубернетес — это ответ!», «Микросервисы!», «Сервис меш!», «Сесурити полиси!». Все вокруг бегут в светлое будущее.

Подходы в том, что касается баз данных, в нашей компании более консервативны, чем в прикладных приложениях. Крутится база данных у нас не в кубернетесе, а на железе или в виртуалке. Для изменений базы данных процессинга платежных сервисов у нас есть устоявшийся процесс, который включает в себя множество автоматических проверок, большое ревью и релиз с участием DBA. Количество проверок и привлекаемых людей в этом случае негативно влияет на time-to-market. С другой стороны, он отлажен и позволяет надежно вносить изменения в продакшен, минимизируя вероятность что-то сломать. А если что-то сломалось, то нужные люди уже включены в процесс починки. Этот подход делает работу основного сервиса компании стабильнее.

Большинство новых реляционных баз данных для микросервисов мы заводим на PostgreSQL. Отлаженный процесс для Oracle хоть и надёжный, но несет с собой избыточную сложность для маленьких БД. Тащить тяжёлые процессы из прошлого в светлое будущее никто не хочет. Проработкой процесса для светлого будущего заранее никто не занялся. В итоге получили отсутствие стандарта и разножопицу.

Как мы в 2020 году изобретали процесс разработки, отладки и доставки в прод изменений базы данных - 1

Если хотите узнать, к каким проблемам это привело и как мы их порешали, — добро пожаловать под кат.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js