Рубрика «Анализ и проектирование систем» - 13

Сервисы падали, падают и будут падать

Когда вы быстро растете, микросервисы начинают появляться буквально по щелчку пальцев и в самых неожиданных местах. В таких условиях каждая команда обычно на ходу решает, где, как и какие логи будет складывать. Когда сначала 10, потом 20, а там и более команд логируют по-своему, начинается хаос.

Трассировка и логирование в микросервисах: как мы втаскивали единый стандарт на 30 независимых команд - 1

Например, наша команда сопровождения маркетинга в Skyeng знала: пользователь с таким-то айдишником нажал в личном кабинете кнопку «Сменить преподавателя» — постучался в наш сервис, дальше ушло три сообщения, в очереди было 2 вызова сервисов и эти сервисы ответили 200. Но на самом деле, что было у команд сопровождения учителей или биллинга, к которым мы стучались, не знал никто…

Тогда мы придумали инструмент, чтобы маркировать трафик

Читать полностью »

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

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

  • Есть несколько продуктов.

  • Один продукт могут делать несколько команд дизайнеров и разработчиков.

  • Есть Web, Mobile и Desktop.

  • Есть много легаси и неконсистентности.

  • Дизайнер в одном продукте может не знать что происходит в другом.

Читать полностью »

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

Читать полностью »

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

Мы отрендерили миллион страниц, чтобы понять, из-за чего тормозит веб - 1

  • Посещён 1 миллион страниц
  • Записано по 65 метрик каждой страницы
  • Запрошен 21 миллион URL
  • Зафиксировано 383 тысячи ошибок
  • Сохранено 88 миллионов глобальных переменных

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

Зачем рендерить миллион веб-страниц?

Сегодня распространено мнение о том, что веб почему-то стал более медленным и забагованным, чем 15 лет назад. Из-за постоянно растущей кучи JavaScript, фреймворков, веб-шрифтов и полифилов, мы съели все преимущества, которые даёт нам увеличение возможностей компьютеров, сетей и протоколов. По крайней мере, так утверждает молва. Мы хотели проверить, правда ли это на самом деле, а также найти общие факторы, которые становятся причиной торможения и поломок сайтов в 2020 году.

Общий план был простым: написать скрипт для веб-браузера, заставить его рендерить корневую страницу миллиона самых популярных доменов и зафиксировать все мыслимые метрики: время рендеринга, количество запросов, перерисовку, ошибки JavaScript, используемые библиотеки и т.п. Имея на руках все эти данные, мы могли бы начать задаваться вопросами о том, как один фактор корреллирует с другим. Какие факторы сильнее всего влияют на замедление рендеринга? Какие библиотеки увеличивают время до момента возможности взаимодействия со страницей (time-to-interactive)? Какие ошибки встречаются наиболее часто, и что их вызывает?
Читать полностью »

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

Разработка все еще в процессе (и полностью open source), но уже пройден увлекательный путь от полного непонимания протокола до относительно стабильного клиента. В серии статей я расскажу, с какими сложностями я столкнулся и как с ними боролся. Приёмы, которые я применил, могут быть полезны при разработке клиента для любого бинарного протокола со схемой.


Type Language

Начнем с Type LanguageЧитать полностью »

Как избежать гниения ПО - 1

Недавно я наткнулся на историю столь же удивительную, сколь и ужасную:

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

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

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

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

Я получил от ИТ-директора неожиданное текстовое сообщение. «Простите за беспокойство, у нас огромная проблема. s1X. Можете прилететь сегодня во второй половине дня?» В их терминологии S1X обозначает «хуже, чем уровень серьёзности 1, потому что проблема распространилась на несвязанные с ней части бизнеса».

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

Привет.

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

Для тех кому интересно, продолжение под катом.
Читать полностью »

Привет.

Заканчивается 2020 год, а значит, настало время подвести статистические итоги и составить уже традиционный рейтинг лучших статей Хабра за этот год. Этот рейтинг не является официальным, данные собираются парсером с помощью Python. Сортируя данные по тем или иным параметрам, можно получать разные выборки, что на мой взгляд, даёт довольно неплохие результаты. Для читателей также может быть интересно перечитать какие-то статьи, которые они пропустили в течении года.

Хабрарейтинг 2020: статистика и рейтинг лучших статей за 2020 год - 1

Поехали.
Читать полностью »

Как мы внедряли распределенный кеш на Tarantool в одной АБС - 1

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

В этой статье представлено одно из решений в мире высокой производительности и распределенных систем. Под катом вы найдёте описание всего лишь небольшого ряда задач и проблем, с которыми мы столкнулись, а также некоторые интересные алгоритмы, подходы к построению архитектуры системы, методы оптимизации запросов, ну и немного о процессе разработки и тестирования решения на базе Tarantool — платформы in-memory вычислений с гибкой схемой данных для эффективного создания высоконагруженных приложений.
Читать полностью »

Введение

Читать полностью »


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