Ошибки

Не кажется ли вам странным, что на фоне глобальной цифровизации, развития аппаратных и программных решений, пик популярности форензики как науки уже прошел, а интерес к ней угасает с каждым днем? Старейшие производители и поставщики решений для криминалистических исследований такие, как Guidance Software (Encase Forensics) и AccessData (Forensic Toolkit), "золотой эталон" для экспертов, детективов, следователей, судей и адвокатов, поглощены третьими компаниями. Ряд ведущих специалистов и авторов бестселлеров в области форензики по тем или иным причинам покинули эту область.... а оставшиеся специалисты частенько наступают на одни и те же грабли. Вот об этих "граблях", проблемах и "болевых точках" криминалистов решил порассуждать Игорь Михайлов, ведущий специалист Лаборатории компьютерной криминалистики Group-IB.

1. Ставить на быструю форензику

В мире компьютерных криминалистов довольно долго считались нерушимыми требования о неизменности цифровых доказательств эти принципы были описаны еще в 2000 году в документе "ACPO Good Practice Guide for Digital Evidence".

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

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

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

Несмотря на риск того, что владелец мобильного устройства отдаст удаленную команду сбросить устройство до заводских настроек и информация на нем будет потеряна, криминалисты как правило не применяют дополнительные средства защиты мобильных устройств: мешки, боксы или сетки Фарадея (изделия, блокирующие электромагнитное излучение в радиодиапазоне).

Наиболее распространенный прием защиты информации, используемый при изъятии мобильного устройства перевести его в режим полета или выключить. Однако в некоторых случаях это не защищает информацию на устройстве от изменения, а иногда и от уничтожения. Кроме того, ряд производителей, например, Apple, экспериментируют с взаимодействием выключенного устройства с другими устройствами подсистемы Apple по протоколу Bluetooth. В перспективе это может позволить владельцу устройства взаимодействовать даже с выключенным аппаратом.

Наши рекомендации:

Соблюдать процедуры криминалистически правильного изъятия носителей информации, использовать клетки Фарадея.

2. Слепо доверять результатам работы программ-комбайнов

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

В совокупности с большим потоком цифровых носителей, поступающих к криминалистам, это привело к такому явлению, как Кнопочная форензика (Push Button Forensics). Исследователь обрабатывает поступающие к нему носители информации этой программой и передает сгенерированные ею отчеты заказчику, не анализируя результаты и не проверяя их на достоверность и полноту. Увы, подобная работа быстро приводит к деградации специалистов в профессиональном плане. У них пропадает понимание того, почему получен именно такой результат, а не иной.

Наши рекомендации:

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

3.Неэффективно использовать программные и аппаратные средства

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

К сожалению, политика добралась и до форензики. Часть криминалистических технологий и оборудования и раньше не поставлялась западными разработчиками в Россию. В этом году наибольший резонанс вызвало то, что израильская компания Cellebrite отказалась поставлять оборудование для криминалистического исследования мобильных устройств. Компания объяснила свое решение тем, что это оборудование якобы использовалось для попыток (попыток!) взлома устройств, изъятых у оппозиционера Любови Соболь. Между тем доподлинно известно, что взломать эти устройства с помощью оборудования Cellebrite невозможно у него просто нет такого функционала.

Наши рекомендации:

Постарайтесь научиться работать с минимальным набором инструментов, но использовать его максимально эффективно.

4. Не перепроверять получаемые результаты и не относиться к ним критически

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

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

Наши рекомендации:

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

5. Плохо подготовиться к изъятию накопителей информации

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

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

Наши рекомендации:

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

6. Использовать распознавание текста в графических файлах и видеофайлах

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

7. Следовать популярным тенденциям вопреки здравому смыслу

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

8. Пытаться делать все одним специалистом

Напомню, что есть следующие виды компьютерно-технической экспертизы:

• аппаратно-компьютерная;

• программно-компьютерная;

• информационно-компьютерная;

• компьютерно-сетевая.

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

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

Наши рекомендации:

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

9. Работать без профильного образования и с низким уровнем подготовки

В России специальность компьютерного криминалиста можно получить только в двух вузах. Первый Московский государственный технический университет имени Н.Э. Баумана. Там на кафедре юриспруденции готовят специалистов по судебной компьютерно-технической экспертизе. Второй вуз это ведомственное учреждение, Воронежский институт МВД. Он проводит обучение по специальности Компьютерная безопасность со специализацией Информационно-аналитическая и техническая экспертиза компьютерных систем. Кроме того, на базе этого вуза проходят повышение квалификации сотрудники экспертно-криминалистических подразделений МВД, занимающиеся компьютерными экспертизами.

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

Еще одна проблема отсутствие в вузах преподавателей, которые бы, c одной стороны, занимались практической деятельностью, связанной с форензикой, а с другой стороны обучением. Это необходимо, чтобы преподаватель понимал, чему и как учить студентов, актуализировал учебные материалы под существующие тренды в форензике.

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

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

Наши рекомендации:

Пройдите учебные курсы на базе образовательных учреждений. Повысить квалификацию можно на курсах, проводимых HackerU, Академией информационных систем, учебными центрами Информзащита и Специалист, Group-IB и Kaspersky.

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

10. Остановиться в своем развитии, пеняя на необъективный рынок труда

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

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

На рынке труда складывается уникальная ситуация. Работодатели предъявляют высокие требования к компетенциям криминалистов, но обычно не готовы адекватно оценивать их работу. Например, от специалиста в области форензики, требуется знание основ обратной разработки (реверса). При этом специалисту в области реверса готовы платить на 20-35% больше, чем специалисту в области форензики (причем требования к реверс-инженеру в целом значительно ниже). Еще печальнее ситуация выглядит, если сравнить уровень зарплат криминалиста и программиста и требования к ним. Криминалисту приходится тратить гораздо больше усилий, чтобы получать столько же или меньше, чем специалисты из смежных областей. Подобные условия приводят к оттоку специалистов из форензики в другие области, связанные с информационными технологиями, программированием и информационной безопасностью.

Наши рекомендации:

Покажите работодателю, насколько важна ваша работа и насколько вы ценный специалист.

Вывод? Мне кажется, он достаточно простой: форензика переживает непростые времена. Для того, чтобы она могла и дальше защищать интересы пользователей и бизнеса, нужно переосмыслить место этой научной дисциплины в сегодняшнем мире или трансформировать ее в соответствии с современными тенденциями и потребностями общества.

Вот пример для проверки:

#include <iostream>int main(){    std::cout << "-3/3u*3 = " << int(-3/3u*3) << "\n";}

Посмотреть результат можно тут.

Или попробуйте поиграться с этим примером здесь или здесь.

Вообще-то мне не удалось найти хоть какой-то компилятор С++, который бы выдавал результат отличный от -4. Даже старый GCC-4.1.2, clang-3.0.0 или Borland C 1992 года. Так же заметил, что результат одинаковый и для константы, вычисляемой в момент компиляции и для времени выполнения.

Предлагаю внимательно рассмотреть результат выражения -3/3u*3.

Если убрать приведение к типу intв примере выше, то получим 4294967292 или 0xFFFFFFFС(-4). Получается, что компилятор на самом деле считает результат беззнаковым и равным 4294967292. До этого момента я был свято уверен, что если в выражении используется знаковый тип, то и результат будет знаковым. Логично же это.

Если посмотреть откуда берется -4 вместо -3, посмотрим внимательней на ассемблерный код примера, например здесь.

Пример изменю, чтобы результат вычислялся не в момент компиляции, а в момент выполнения:

int main(){    volatile unsigned B = 3;    int A = -3/B*3;}

Для x86-64 clang 12.0.0 видим, что используется беззнаковое деление, хотя числитель откровенно отрицательное -3:

        mov     dword ptr [rbp - 4], 3    // B = 3        mov     ecx, dword ptr [rbp - 4]        mov     eax, 4294967293        xor     edx, edx        div     ecx                       // беззнаковое деление !!        imul    eax, eax, 3               // знаковое умножение        mov     dword ptr [rbp - 8], eax

Для x64 msvc v19.28 тот же подход к делению:

        mov     DWORD PTR B$[rsp], 3      // B = 3        mov     eax, DWORD PTR B$[rsp]        mov     DWORD PTR tv64[rsp], eax        xor     edx, edx        mov     eax, -3                             ; fffffffdH        mov     ecx, DWORD PTR tv64[rsp]        div     ecx        imul    eax, eax, 3        mov     DWORD PTR A$[rsp], eax

Получается, что для деления беззнакового числа на знаковое используется БЕЗЗНАКОВАЯ операция деления процессора div. Кстати, следующая команда процессора, это правильное знаковое умножение imul. Ну явный баг компилятора. Банальная логика же подсказывает, что знаковый тип выиграет в приведении типа результата выражения если оба знаковый и беззнаковый типы используются в выражении. И для знакового деления требуется знаковая команда деления процессора idiv, чтоб получить правильный результат со знаком.

Проблема еще и в том, что число 4294967293 не делится на 3 без остатка:4294967293 = 1431655764 * 3 + 1и при умножении 1431655764 обратно на 3, получаем 4294967292 или -4. Так что прикинуться веником и считать, что 4294967293 это то же -3, только вид сбоку, для операции деления не прокатит.

Я когда обнаружил, что используется без-знаковое деление, решил, что это бага компилятора. Протестировал много компиляторов: msvc, gcc, clang. Все показали такой же результат, даже древние трудяги. Но мне довольно быстро подсказали, что это поведение описано и закреплено в самом стандарте.

Действительно, стандарт говорит об этом прямо:

Otherwise, if the unsigned operand's conversion rank is greater or equal to the conversion rank of" "the signed operand, the signed operand is converted to the unsigned operand's type.

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

Вот где оказывается собака зарыта: "the signed operand is converted to the unsigned operand's type"!! Ну почему, почему, Карл!! Логичнее наоборот: "the unsigned operand is converted to the signed operand's type", разумеется при соблюдении ранга преобразования. Ну вот как -3 представить без-знаковым числом?? Наоборот кстати можно.

Интересная получается сегрегация по знаковому признаку!

Заметил, что это правило почему-то работает только для операции деления, а операция умножения вычисляется правильно.

Проверим на ассемблере здесь этот пример:

int main(){    volatile unsigned B = 3;    int C = -3*B;}

Стандарт ничего не говорит о неприменимости этого правила для операции умножения. И деление и умножение должны быть БЕЗЗНАКОВМИ.

Я подумал, что что-то в стандарте сломалось и надо срочно это исправить. Написал письмо напрямую в поддержку Стандарта со всеми моими выкладками и предложением поправить это странное правило стандарта пока еще не поздно.

Ага! Наивный!

Мне ответил любезный молодой сотрудник из Стандарта и подтвердил, что мои выкладки правильны, логика на моей стороне, но поведение компиляторов полностью согласуется со Стандартом и само правило менять не будут, так как оно такое древнее, что непонятно кто и когда его ввел (сотрудник сказал, что искал автора, но не нашел) и поэтому его, как святую корову, трогать никто не будет, хотя вроде логично было бы исправить. Ну и милостиво разрешил поведать эту историю миру. О чем и пишу.

Хоть это исследование и было больше года назад, я до сих пор под впечатлением от многих вещей в этой истории:

• Как я не натыкался на это раньше? Не один десяток лет интенсивно кодирую на С и С++ с погружением в ассемблер, но только сейчас споткнулся на неё. Хотя может и натыкался ранее, но не мог поверить что причина именно в этом.

• Ассемблер я выучил раньше С и поэтому всегда считал С удобной заменой Ассемблера. Но правила работы процессоров неизменны и даже языки высокого уровня им следуют.

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

int main(){    const unsigned a[] = {3,4,5,6,7};    unsigned p = (&a[0] - &a[3])/3u*3;    // -3    unsigned b = -3/3u*3;   // -4}

Хоть я и понимаю, что могу ошибаться в логике работы этого мира, но задумайтесь, в следующий раз садясь в современный, нашпигованный вычислительной логикой самолёт (или автомобиль), а не сработает ли вдруг не оттестированный кусок кода в какой-то редкой нештатной ситуации, и не выдаст ли он -4 вместо элементарных -3, и не постигнет ли его участь подобная Boeing 737 MAX?

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

Предвижу возражение, что есть рекомендация использовать преимущественно без-знаковый тип. Понимаю, с таким правилом Стандарта по другому никак. Но как -4 в беззнаковое перевести, и чтоб всё остальное работало? И почему на других языках и всех процессорах не надо этими танцами с бубном заниматься, а в С++ надо? И что делать с константными выражениями, вычисляемыми компилятором? Вместо элегантных выражений, в которых мы уверены, надо записывать их с оглядкой, чтоб у компилятора небыло изжоги!

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

Как хорошую подсказку познавательно добавить предупреждение в компилятор когда он применяет это правило из Стандарта:"Signed value is intentionally converted to unsigned value. Sorry for crashing one more airplane. Have a nice flight!" Вот удивимся тогда, как мало мы тестируем и как много нам открытий чудных приносит компилятор друг.

Можно еще исправить Стандарт, ограничив правило только операциями сложения и вычитания. Как компромис. Но это крайне маловероятно в этой Вселенной. Да и Боингов еще много летает.

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

Info: все ожидаемые события, учет которых запланирован.
Warning: неожиданные/подозрительные события - иначе говоря аномалии, после которых еще возможно продолжение работы приложения.
Error: событие, после которого невозможно дальнейшее выполнение программы.
Fatal: событие, требующее по-настоящему немедленного вмешательства.

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

"Продолжить работу"

Трактовать возможно продолжить работу можно очень по разному. Скажем, на экране пользователя можно настроить любимый цвет рамки вокруг экрана: пусть будет розовый. Если по каким-то причинам хранилище, где мы держим эти настройки цвета было недоступно и мы не можем отобразить этот цвет - можно ли это считать как возможно продолжить или это катастрофа? К сожалению, я еще ни разу не встречал хорошего универсального формального критерия, чтобы четко можно было разделять "катастрофа-терпимо". А раз не можешь остановить - значит нужно направить. Потому я предлагаю инвертировать споры об это неправильный уровень: если в коде написано, что отсутствие цвета - это Error - значит программист Вам говорит, что этот цвет чертовски важен в этом домене - возможно, именно этот цвет сигнализирует, что сейчас надо продавать акции на миллионы долларов, и наоборот. Соответственно, чтение кода немного меняется: когда видите место, где из-за какой-то на Ваш взгляд ерунды прерывается выполнение, вопрос, который должен возникать автору, Почему ты считаешь, что это так важно? вместо Истинно тебе говорю - ты программируешь неправильно!.

Схожая инверсия может помочь в вечных спорах на тему это исключительная ситуация или нет. Опять же, все довольно просто. Важна не техническая составляющая: нет соединения к базе - это исключение, а серверу прислали неправильный id - так это ожидаемо. Важно то,чья это будет головная больи как ее можно избежать или хотя бы минимизировать урон. Чьи планы на вечер пятницы пойдут к черту из-за того, что это сломалось? Если Вашим сервисом пользуются приложения, которые вне Вашего контроля, то Вам действительно плевать на то, что они присылают некорректные id и у них там что-то идет не так. Если Ваше приложение - это инструмент для управления базой данный - наподобие Sql Server Magement Studio - очевидно, что отсутствие доступа к базе - не Ваша печаль. А если Вашим сервисом пользуются приложения, за которые Вы же и в ответе - то это Ваши неприятности в конечном счете. Вопрос лишь в том, как и когда Вы об этом узнаете - быстро из сработавшей сигнализации или от звонка злого как черт владельца бизнеса, которому Вы пишете софт. А также вопрос в том, как дешево, надежно и сердито эту сигнализацию наладить.

"Error"

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

На практике сообщение вида Обратитесь к администратору это просто подслащенные крэш. Да, несомненно это лучше, чем убить весь процесс со всеми пользовательскими данными, но от этого оно не перестает фактически блокировать работу. В тоже время ошибка может быть сообщением о неправильных с точки зрения программы действиях, а именно надо было ввести имя и фамилию Джон Иванов, а человек ввел просто Джон и валидатору это не нравится. К чему это все? Что вообще у нас тут речь идет о 3-х достаточно разных сущностях, но при том на каждую из них можно сослаться как Error, что вызывает изрядную путаницу. Крэш приложения - это несомненно уровень Error в нашей системе определений, но это очень важный Error.

Ошибка валидации имя-фамилии - это несомненно уровень Info - мы ждем, что пользователь будет норовить записать все что угодно, а мы - пресекать это. Ну и записывать все те разы, когда пользователь был неправ. Но от этого ошибки не перестают бесить людей, которые их видят. То, что напрямую связано с людьми и их UX - важно; и неплохо бы присматривать за этим, не допускать, чтобы сообщения об этом тонули в километрах унылых Info записей Пользователь такой-то залогинился. Иными словами, чтобы устранить путаницу, хочется иметь уровни Error+ и Info+.

Я предвижу восклицания Так погодите, ведь крэш приложения - это недопустимо! Надо сразу действовать! Это Fatal уровень!" На это я неспеша прикурю воображаемую сигарету, затянусь и задумчиво отвечу: Ну всех ведь все равно не спасти...". Ладно, я не курю, но, думаю, образ понятен. Появление сообщения Fatal должно быть эквивалентом запуска тревоги воздушной угрозы, когда в офисе разработки врубается сирена и это жуткое красное аварийное освещение. Вот честно, Вы именно так реагируете на то, что у кого-то из бухгалтерии на экране, который раз в сто лет запускают, упало приложение? Вполне может быть нормально, что у Вас сейчас даже и нет подобной ситуации, где уровень Fatal - согласно такой системы определений - нужен. Так вот трюк в том, чтобы не блокировать возможность добавить обработку такой потенциальной ситуации в будущем, забивая сейчас Fatal уровень сообщениями, которым важностьError+ в самый раз.

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

Info
Info+
Warning
Error
Error+
Fatal

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

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

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

Почему время загрузки страницы важно?

Время загрузки страницы напрямую связано с производительностью сайта.

Если загрузка занимает более 3 секунд, вы потеряете половину посетителей еще до того, как они попадут на ваш сайт.

• Видимость - Google учитывает время загрузки страницы при ранжировании в результатах поиска. Следовательно, время загрузки сайта влияет на то, насколько легко пользователи смогут найти его в Интернете.

• Конверсия - чем быстрее загружается страница, тем больше пользователи взаимодействуют с сайтом. Медленные сайты убивают конверсии. Потенциальные клиенты будут неохотно пользоваться сайтом и следовать призывам к действию (CTA), если ваша веб-страница будет долго загружаться. Это приведет к разочарованным пользователям, они будут уходить с сайта, не покупая ваш продукт или не используя ваши услуги.

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

Давайте рассмотрим несколько примеров, основанных на исследовании, проведенном HubSpot.

• Если Yahoo сократит время загрузки страницы на 0,4 секунды, трафик может увеличиться на 9%.

• Замедление загрузки страницы на 1 секунду может стоить Amazon 1,6 миллиарда долларов продаж в год.

• 2-секундная задержка поиска Bing приведет к потере дохода на 4,3% на посетителя, уменьшению числа кликов на 3,75% и сокращению количества запросов на 1,8%.

Согласно приведенным выше фактам, можно увидеть, насколько важно время загрузки страницы.

Факторы, влияющие на время загрузки страницы, а также советы и рекомендации по оптимизации

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

1. Большое количество HTTP-запросов

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

Браузер обычно ограничивает количество одновременных запросов от 4 до 8. Следовательно, нельзя делать много запросов параллельно.

Исследования, проведенные Yahoo, показывают, что 80% времени загрузки приложения зависит от HTTP-запросов.

Можно сделать следующее, чтобы уменьшить количество HTTP-запросов:

• Объединение файлов CSS / JS - файлы CSS, а также файлы JS можно объединить в один файл, а не получать несколько файлов с сервера. Поскольку все файлы CSS блокируют рендеринг, уменьшение количества файлов CSS значительно сократит время загрузки страницы.

• Загружать только то, что необходимо - вместо загрузки всех изображений сразу загружайте их только тогда, когда они необходимы. Этот способ называется отложенной загрузкой или загрузкой по требованию. Например, когда пользователь заходит на сайт, вместо загрузки изображения, находящегося внизу страницы, вы можете загрузить его, когда пользователь прокручивает до этого конкретного места.

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

• Поддержка HTTP/2 на сервере. При использовании HTTP/2 из браузер выполняет только одно соединение с сервером для загрузки сайта, и одновременно разрешается несколько запросов. Это намного эффективнее, чем создавать новое соединения для каждого ресурса.

2. Отсутствие CDN

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

Использование CDN сокращает время загрузки страницы.

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

Например, если ваш исходный сервер находится в Калифорнии, ваша CDN может выглядеть следующим образом.

Однако также важно правильно настроить CDN для кэширования контента с правильными значениями TTL для эффективного использования.

Но что происходит с самым первым запросом или когда срок действия кэша CDN истечет?

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

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

Совет: делитесь повторно используемыми компонентами между проектами с помощью Bit (Github).

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

Bit поддерживает Node, TypeScript, React, Vue, Angular и др.

3. Большие размеры файлов и размер страницы

Получение большого файла или страницы с веб-сервера занимает много времени. Выборка нескольких таких больших файлов увеличивает размер страницы и увеличивает время загрузки страницы.

Уменьшение размеров файлов за счет сжатия может сократить время загрузки страницы.

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

Доступна другая схема сжатия, сжатие Brotli, которую вы также можете использовать в зависимости от типов файлов.

Сжатие файлов HTML или CSS обычно экономит около 50% или 70% размера файла, что приводит к меньшему времени загрузки страницы и меньшей пропускной способности.

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

4. Загрузка всех ресурсов одновременно

Одновременная загрузка всех файлов HTML, CSS и JS увеличивает время загрузки страницы, так как отрисовка будет заблокирована до тех пор, пока не будут загружены все эти ресурсы.

Загрузка файлов JS после других элементов улучшает время загрузки страницы.

Отложенная загрузка JavaScript - это механизм загрузки больших файлов JS после других элементов. Этот метод гарантирует, что остальная часть вашего контента загружается без каких-либо блокировок большими JS-файлами.

Пусть у вас есть HTML, вам нужно сделать вызов внешнего JS-файла (defer.js) перед тегом </body>.

<script type="text/javascript"> function downloadJSAtOnload() {   var element = document.createElement("script");   element.src = "defer.js";   document.body.appendChild(element); } if (window.addEventListener)   window.addEventListener("load", downloadJSAtOnload, false); else if (window.attachEvent)   window.attachEvent("onload", downloadJSAtOnload); else window.onload = downloadJSAtOnload;</script>

Смысл приведенного выше кода: Подождите, пока загрузится весь документ, затем загрузите файл defer.js.

5. Большое количество переадресаций

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

Можно использовать такой инструмент, как Screaming Frog, чтобы идентифицировать все перенаправления в приложении. Анализируя результат, вы сможете убрать ненужные.

Что касается переадресации, существует два типа:

• на стороне сервера - быстрые и кэшируемые

• на стороне клиента - медленные и не кэшируемые

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

Заключение

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

Для оценки производительности своего веб-сайта можно использовать множество инструментов, таких как Google Pagespeed Insights, Pingdom, YSlow и т.д. Они дадут некоторое представление о том, в каком месте сайт тормозит.

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

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

У нас в Badoo довольно много клиентских приложений. Помимо основных продуктов Badoo и Bumble, у которых есть как веб-версии (десктопная и мобильная), так и клиенты под нативные платформы (Android и iOS), ещё есть с десяток внутренних инструментов со своими UI. Для сбора клиентских ошибок мы используем собственную разработку под кодовым названием Gelatо. Последние два года я работал над её серверной частью и за это время открыл для себя много нового из мира разработки Error Tracking систем.

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

Что вас ждёт:

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

• дам краткий обзор нашей системы, её архитектуры и технологического стека;

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

Как мы используем информацию об ошибках

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

Второе проводим анализ ошибок. Мы в Badoo релизимся довольно часто:

веб-приложения: один-два раза в день, включая серверную часть;

нативные приложения: раз в неделю (хотя многое зависит от того, как быстро билд примут в App Store и Google Play).

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

Третье. Информация об ошибках, собранная в одном месте, значительно упрощает работу разработчиков и QA-инженеров.

Что использовали раньше

Исторически для сбора клиентских ошибок в Badoo использовались две системы: HockeyApp для сбора краш-репортов из нативных приложений и самописная система для сбора JS-ошибок.

HockeyApp

HockeyApp полностью удовлетворяла наши потребности, до тех пор пока в 2014 году её не приобрела Microsoft и не начала менять политику использования, чтобы подтолкнуть людей к переходу на свою систему App Center. App Center на тот момент нашим требованиям не соответствовала: она находилась на стадии активной разработки, и часть необходимой нам функциональности отсутствовала, в частности деобфускация стек-трейсов Android-приложений с использованием DexGuard mapping-файлов, без которой невозможна группировка ошибок. О деобфускации я расскажу ниже; если вы слышите об этом впервые, значит, точно узнаете что-то новое.

Microsoft установила дедлайн 16 октября 2019 года, к этому дню все пользователи HockeyApp должны были мигрировать в App Center. К слову, поддержка DexGuard появилась в App Center лишь в конце декабря 2019 года, спустя несколько месяцев после официального закрытия HockeyApp.

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

Наша система для сбора JS-ошибок

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

Архитектура у неё была довольно простой:

• данные хранились в MySQL (мы хранили информацию о последних 1020 релизах);

• для каждой версии приложения была отдельная таблица;

• работал поиск по фиксированному набору полей средствами MySQL, плюс мы использовали Sphinx для полнотекстового поиска.

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

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

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

Требования к новой системе

• Хранение всех клиентских ошибок в одном месте.

• Хранение событий минимум за полгода без семплирования. При исследовании фантомного бага (бага, у которого нет чёткого сценария воспроизведения) возможность посмотреть ошибки для конкретного пользователя в определённый момент времени может значительно облегчить жизнь инженера. Поэтому чем больше информации мы можем хранить, тем лучше.

• Лёгкое масштабирование. Периодически случаются ошибки, которые порождают миллионы событий. Система должна быть способна обработать такой поток данных.

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

• Способность давать ответ не только на вопрос Сколько произошло ошибок?, но и на вопрос Сколько пользователей это затронуло?.

• Группировка похожих ошибок с сохранением мета-информации (время первой и последней ошибки в группе, в каком релизе появилась ошибка, статус ошибки и т. п.).

• Гибкий поиск по любой комбинации полей с поддержкой полнотекстового поиска.

• Разнообразная статистика: количество ошибок за период, количество ошибок в разбивке по релизам, по браузерам, по операционным системам и т. п.

• Интеграция с Jira. Наша разработка ведётся с использованием Jira, поэтому нам необходима возможность создавать тикеты для определённых ошибок.

• Self-hosted. Мы хотим, чтобы система работала на нашем железе. Это обеспечит нам полный контроль над данными и возможность в любой момент изменить конфигурацию кластера.

Почему мы не выбрали готовое решение

Конечно, прежде чем писать своё решение, мы проанализировали существующие на рынке системы.

Платные сервисы

Сбором клиентских ошибок занимаются многие SaaS-решения, и это неудивительно: быстрое обнаружение и исправление ошибок один из ключевых аспектов современной разработки. Среди самых популярных решений можно выделить Bugsnag, TrackJS, Raygun, Rollbar и Airbrake. Все они обладают богатым функционалом и в целом соответствуют нашим требованиям, но мы не рассматривали облачные решения: не было уверенности в том, что ценовая политика и политика использования со временем не изменятся, как это случилось с HockeyApp. А миграция на новое решение довольно сложная и длительная процедура.

Open-source-решения

С open-source-системами всё было не так радужно. Большинство из них либо перестали развиваться, либо так и не вышли из стадии разработки и были непригодны для использования в продакшене.

Фактически лишь Sentry продолжал активно развиваться и обладал функциональностью, покрывающей большую часть наших потребностей. Но на тот момент (начало 2018 года) восьмая версия сервиса не подошла нам по следующим причинам:

• вместо хранения всех событий в ней использовалось семплирование;

• в качестве базы данных использовалась PostgreSQL, с которой у нас не было опыта работы;

• были сложности с добавлением новой функциональности, так как система написана на Python, а наши основные языки PHP и Go;

• отсутствие части необходимой нам функциональности (например, интеграции с Jira).

В июле 2018 года вышла девятая версия Sentry, в которой появилась интеграция с issue-трекерами и был заложен фундамент для одного из ключевых, на мой взгляд, улучшений перехода на ClickHouse для хранения событий (рекомендую к прочтению серию статей об этом). Но к сожалению, на момент нашего ресёрча всего этого ещё не было даже в планах. Поэтому мы решили, что оптимальным вариантом в нашем случае будет реализация собственной системы, заточенной под наши процессы, которую легко интегрировать с другими внутренними продуктами.

Так на свет появилась система под кодовым названием Gelato (General Error Logs And The Others), о разработке которой и пойдёт речь дальше.

Краткий обзор системы

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

На главной странице находятся список приложений и общая статистика ошибок по заданному критерию.

Кликнув на то или иное приложение, мы попадём на страницу со статистикой по его релизам.

Кликнув на версию, мы попадём на страницу со списком ошибок.

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

Так эта страница выглядит для нативных приложений:

Кликнув на ошибку, мы попадём на страницу с детальной информацией о ней.

Здесь доступны общая информация об ошибке (1), график общего количества ошибок (2) и различная аналитика (3).

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

Ещё одна интересная возможность, которую я не встречал в аналогичных системах, сравнение версий. Это позволяет довольно легко обнаруживать ошибки, которые появились в новой версии, и те, что были исправлены в прошлых релизах, но начали воспроизводиться снова спустя какое-то время (регресс).

Выбираем версии для сравнения:

И попадаем на страницу со списком ошибок, которые есть в одной версии и которых нет в другой:

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

• интеграция с нашим A/B-фреймворком для отслеживания ошибок, которые появились в том или ином сплит-тесте;

• система уведомлений о новых ошибках;

• расширенная аналитика (больше графиков и диаграмм);

• email-дайджесты со статистикой по приложениям.

Общая схема работы

Теперь поговорим о том, как всё устроено под капотом. Схема довольно стандартная и состоит из трёх этапов:

1. Сбор данных.

2. Обработка данных.

3. Хранение данных.

Схематически это можно изобразить следующим образом:

Давайте для начала разберёмся со сбором данных.

Сбор данных

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

Что входит в задачи API:

• прочитать данные;

• проверить данные на соответствие требуемому формату, чтобы сразу отсечь шум (чаще всего это запросы от мамкиных хакеров, которые натравили сканеры на наше API);

• сохранить всё в промежуточную очередь.

Для чего нужна промежуточная очередь?

Если полагаться на то, что у нас достаточно низкий EPS (errors per second), и на то, что все части нашей системы будут работать стабильно всё время, то можно значительно упростить систему и сделать весь процесс синхронным.

Но мы-то с вами знаем, что в реальном мире так не бывает и на каждом из этапов в самый неподходящий момент может произойти нечто непредвиденное. И к этому наша система должна быть готова. Так, ошибка в одной из внешних зависимостей приложения приведёт к тому, что оно начнёт крашиться, что повлечёт за собой рост EPS (как это было с iOS Facebook SDK 10 июля 2020 года). Как следствие, значительно увеличится нагрузка на всю систему, а вместе с этим и время обработки одного запроса.

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

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

Что можно использовать в качестве очереди?

1. Первое, что приходит в голову, популярные брокеры сообщений, например Redis или RabbitMQ.

2. Также можно использовать Apache Kafka, которая хорошо подходит для случаев, когда требуется хранить хвост входящих данных за определённый период (например, для какой-то внутренней аналитики). Kafka используется в частности в последней (десятой) версии Sentry.

3. Мы остановились на LSD (Live Streaming Daemon). По сути, это очередь на файлах. Система используется в Badoo довольно давно и хорошо себя зарекомендовала, плюс у нас в коде уже есть вся необходимая обвязка для работы с ней.

Хранение данных

Тут нужно ответить на два вопроса: Где хранить? (база данных) и Как хранить? (модель данных).

База данных

При реализации прототипа системы мы остановились на двух претендентах: Elasticsearch и ClickHouse.

Elasticsearch

Из очевидных плюсов данной системы можно выделить следующие:

• горизонтальное масштабирование и репликация из коробки;

• большой набор агрегаций, что удобно при реализации аналитической части нашей системы;

• полнотекстовый поиск;

• поддержка UPDATE по условию (процесс обработки данных у нас асинхронный, и нужна возможность выполнять некоторые шаги пайплайна повторно, а значит, и возможность обновлять определённые поля у конкретных событий);

• поддержка DELETE по условию (мы храним данные за полгода, а значит, нам нужна возможность удалять устаревшие данные);

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

Конечно, как у любой системы, у Elasticsearch есть и недостатки:

• сложный язык запросов, поэтому документация всегда должна быть под рукой (в последних версиях появилась поддержка синтаксиса SQL, но это доступно только в платной версии (X-Pack) либо при использовании Open Distro от Amazon);

• JVM, которую нужно уметь готовить, в то время как наши основные языки это PHP и Go (например, для оптимизации сборщика мусора под определённый профиль нагрузки требуется глубокое понимание того, как всё работает под капотом; мы столкнулись с этой проблемой при обновлении с версии 6.8 до 7.5, благо тема не нова и есть довольно много статей в интернете (например, тут и тут));

• плохое сжатие строк; мы планируем хранить довольно много данных и, хотя железо с каждым годом дешевеет, хотим использовать ресурсы максимально эффективно (конечно, можно использовать deflate-сжатие вместо LZ4, но это увеличит потребление CPU, что может негативно сказаться на производительности всего кластера).

ClickHouse

Плюсы данной базы:

• отличная производительность на запись;

• хорошее сжатие данных, особенно длинных строк;

• MySQL-совместимый синтаксис запросов, что избавляет от необходимости учить новый язык запросов, как в случае с Elasticsearch;

• горизонтальное масштабирование и репликация из коробки, хоть это и требует больше усилий по сравнению с Elasticsearch.

Но на начало 2018 года в ClickHouse отсутствовала часть необходимых нам функций:

• Поддержка DELETE по условию (мы планировали хранить данные за полгода, поэтому нам была необходима возможность удаления устаревших данных; в ClickHouse удаление данных по произвольному критерию предусмотрено не было, а партиционирование по произвольному полю (в нашем случае по дате) на тот момент находилось на стадии экспериментальной фичи и не рекомендовалось к использованию в продакшене);

• поддержка UPDATE по условию: ClickHouse заточена под неизменяемые данные, поэтому реализация обновления произвольных записей задача не из лёгких (этот вопрос не раз поднимался на GitHub и в конце 2018 года функцию всё же реализовали, но она не подходит для частых обновлений);

• полнотекстовый поиск (была опция поиска по RegExp, но он требует сканирования всей таблицы (full scan), а это довольно медленная операция).

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

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

Модель данных

Теперь немного поговорим о том, как мы храним события.

Все данные у нас разбиты на несколько групп и хранятся в отдельных индексах:

• мета-информация;

• сырые события.

Данные изолированы в рамках конкретного приложения (отдельный индекс) это позволяет кастомизировать настройки индекса в зависимости от нагрузки. Например, для непопулярных приложений можно хранить данные на warm-нодах в кластере (мы используем hot-warm-cold-архитектуру).

Для того чтобы в одной системе можно было хранить и JS-ошибки, и краш-репорты нативных приложений, мы вынесли на верхний уровень всё, что используется для формирования общей статистики (время ошибки, в каком релизе она произошла, информация о пользователе, ключ группировки). А то, что уникально для каждого типа ошибки, хранится во вложенном поле attributes со своим маппингом.

Сама идея была позаимствована из Sentry и незначительно доработана в процессе эксплуатации. В Sentry у события есть базовые поля, есть поле tags для данных, по которым нужна возможность поиска, и поле extra для всех остальных специфических данных.

Обработка данных

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

Начнём со случая попроще.

Обработка краш-репортов из Android-приложений

Чтобы максимально уменьшить размер приложения, в Android-мире принято при сборке билда использовать специальные утилиты, которые:

• удаляют весь неиспользуемый код (code shrinking сокращение);

• оптимизируют всё, что осталось после первого этапа (optimization оптимизация);

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

Подробнее про это можно узнать из официальной документации.

Сегодня есть несколько популярных утилит:

• ProGuard (бесплатная версия);

• DexGuard на базе ProGuard (платная версия с расширенным функционалом);

• R8 от Google.

Если приложение собрано с режимом обфускации, то стек-трейс будет выглядеть примерно так:

o.imc: Error loading resources: Security check requiredat o.mef.b(:77)at o.mef.e(:23)at o.mef$a.d(:61)at o.mef$a.invoke(:23)at o.jij$c.a(:42)at o.jij$c.apply(Unknown Source:0)at o.wgv$c.a_(:81)at o.whb$e.a_(:64)at o.wgs$b$a.a_(:111)at o.wgy$b.run(:81)at o.vxu$e.run(:109)at android.os.Handler.handleCallback(Handler.java:790)at android.os.Handler.dispatchMessage(Handler.java:99)at android.os.Looper.loop(Looper.java:164)at android.app.ActivityThread.main(ActivityThread.java:6626)at java.lang.reflect.Method.invoke(Native Method)at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:811)

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

AllGoalsDialogFragment -> o.a:    java.util.LinkedHashMap goals -> c    kotlin.jvm.functions.Function1 onGoalSelected -> e    java.lang.String selectedId -> d    AllGoalsDialogFragment$Companion Companion -> a    54:73:android.view.View onCreateView(android.view.LayoutInflater,android.view.ViewGroup,android.os.Bundle) -> onCreateView    76:76:int getTheme() -> getTheme    79:85:android.app.Dialog onCreateDialog(android.os.Bundle) -> onCreateDialog    93:97:void onDestroyView() -> onDestroyView

Следовательно, нам нужен сервис, которому мы могли бы скормить обфусцированный стек трейс и mapping-файл и на выходе получить оригинальный стек-трейс.

Нам не удалось найти подходящих готовых решений в открытом доступе (может, конечно, плохо искали), но, к счастью, инженеры ProGuard (а мы используем DexGuard для обфускации) позаботились о разработчиках и выложили в открытый доступ утилиту ReTrace, которая реализует весь необходимый функционал для деобфускации.

На её базе наши Android-разработчики написали простенький сервис на Kotlin, который:

• принимает на вход стек-трейс и версию приложения;

• скачивает необходимый mapping-файл из Ceph (маппинги заливаются автоматически при сборке релиза в TeamCity);

• деобфусцирует стек-трейс.

Обработка краш-репортов из iOS-приложений

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

Thread 0:0   libsystem_kernel.dylib              0x00000001bf3468b8 0x1bf321000 + 1537841   libobjc.A.dylib                     0x00000001bf289de0 0x1bf270000 + 1059522   Badoo                               0x0000000105c9c6f4 0x1047ec000 + 216941963   Badoo                               0x000000010657660c 0x1047ec000 + 309755004   Badoo                               0x0000000106524e04 0x1047ec000 + 306416685   Badoo                               0x000000010652b0f8 0x1047ec000 + 306670006   Badoo                               0x0000000105dce27c 0x1047ec000 + 229464287   Badoo                               0x0000000105dce3b4 0x1047ec000 + 229467408   Badoo                               0x0000000104d41340 0x1047ec000 + 5591872

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

Что можно использовать для символикации?

• Можно написать свой сервис на базе консольных утилит, но, скорее всего, он подойдёт только для ручной символикации и будет доступен только на macOS. У нас же, например, всё работает на Linux.

• Можно взять сервис Symbolicator от Sentry, который недавно был выложен в открытый доступ (рекомендую почитать статью о том, как он разрабатывался). Мы какое-то время экспериментировали с ним и пришли к выводу, что as is этот сервис будет сложно интегрировать в нашу схему: пришлось бы допиливать его под наши нужды, а опыта использования Rust у нас нет.

• Можно написать свой сервис на базе библиотеки Symbolic от Sentry, которая, хоть и написана на Rust, но предоставляет C-ABI её можно использовать в языке с поддержкой FFI.

Мы остановили свой выбор на последнем варианте и написали сервис на Golang с учётом всех наших нюансов, который под капотом обращается к Symbolic через cgo.

Группировка ошибок

И ещё один процесс, которому следует уделить внимание, группировка ошибок. От неё зависит, как быстро вы сможете обнаруживать наиболее критичные ошибки среди всех остальных событий.

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

Мы решили не усложнять свою систему и остановились на группировке по хешу:

• JS-ошибки группируются по полям message, type и origin;

• Android краш-репорты группируются по первым трём строчкам стек-трейсов (плюс немного магии);

• iOS краш-репорты группируются по первому несистемному фрейму из упавшего треда (тред, который отмечен как crashed в краш-репорте).

В качестве заключения

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

Однако если сегодня перед вами стоит задача начать собирать и обрабатывать клиентские ошибки, то я рекомендую присмотреться к Sentry, так как этот сервис активно развивается и является одним из лидеров рынка.

Ну а если вы решите последовать нашему примеру и станете разрабатывать собственную систему, то в этой статье я постарался максимально раскрыть основные моменты, на которые следует обратить внимание.

Если резюмировать, то:

• храните как можно больше данных: это может сэкономить вам драгоценные часы и нервы, которые в противном случае придётся потратить на дебаг;

• будьте готовы к резкому росту количества ошибок;

• чем больше аналитики вы построите, тем лучше;

• символикация iOS краш-репортов это сложно, присмотритесь к Symbolicator;

• предусмотрите систему уведомления о новых ошибках: это даст вам больше контроля и возможность своевременно реагировать на резкий рост ошибок;

• запаситесь терпением и приготовьтесь к увлекательному путешествию в мир разработки систем сбора ошибок.

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

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

Disclaimer: эта статья не является абсолютным правилом, и ваш опыт может отличаться.

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

1. Это ваше первое местое работы

2. Вы работаете там достаточно продолжительное время (1 - 1,5 года +)

3. Вы работаете с одним и тем же лидом/ментором

4. Вы работаете на одном и том же проекте с одинаковым стеком

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

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

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

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

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

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

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

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

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

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

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

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

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

Немного о фрилансе

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

Заключение

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

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

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

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

IELTS это один из двух самых популярных экзаменов для оценки уровня английского языка. Каждый год его проходит свыше 3 млн людей во всем мире.

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

Мы проанализировали советы и рекомендации, которые предоставляет официальный сайт IELTS и выделили несколько распространенных ошибок, которые встречаются чаще всего. О них и поговорим.

Больше всего ошибок допускается на этапах Writing и Speaking. То есть, во время написания текстов и диалога с экзаменатором. Сложность в том, что на этих этапах нужно говорить и писать своими словами, а не выбирать из вариантов или писать краткие ответы из одного или нескольких слов.

Поэтому давайте обратим внимание на распространенные ошибки и важные моменты.

1. Объем текстов в блоке Writing

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

В первом задании нужно написать не менее 150 слов, во втором как минимум 250. Даже если у вас будет 149 и 249 слов соответственно, экзаменатор может поставить за весь блок по нулям.

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

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

Оптимальная тактика написать тексты на 170-280 и 270-280 слов соответственно, а оставшееся время потратить на их вычитку.

2. Слишком много филлеров в Speaking

Вставные слова это хорошо. Они показывают высокий уровень владения языком. Это так, но не совсем.

С одной стороны, носители языка используют много слов-паразитов. И если проанализировать речь среднестатистического американца, она будет наполнена различными well, literally, you know, like и другими.

Но к уровню владения языком это не имеет никакого отношения. Это лишь привычка заполнять пробелы в речи, чтобы не было неловкого молчания.

Знание слов-филлеров и уместное их использование действительно даст вам пару дополнительных баллов у экзаменатора. Но злоупотребление ими и попытки замаскировать паузы для осмысления следующей фразы даже наоборот.

Использовать вставные слова в блоке Speaking вполне нормально. Но оптимальная тактика использовать один филлер не чаще чем на три-четыре предложения.

3. Уход от темы обсуждения

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

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

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

Возьмем для примера реальное задание IELTS с комментариями экзаменаторов.

Текст задания:

Children who are brought up in families that do not have large amounts of money are better prepared to deal with the problems of adult life than children brought up by wealthy parents. To what extent do you agree or disagree with this opinion?

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

Вот один из примеров ответов:

И комментарий экзаменатора по этому заданию.

While it is obviously related to the topic, the introduction is confusing and the test takers position is difficult to identify. Ideas are limited and although the test taker attempts to support them with examples from experience, they remain unclear. There is no overall progression in the response and the ideas are not coherently linked.

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

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

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

4. Важны не идеи, а то, как вы их описываете

Еще одна очень распространенная ошибка попытка блеснуть оригинальным ответом.

Многие забывают, что экзаменатору абсолютно все равно, что именно вы ответите он оценивает язык, а не идею или жизненную позицию.

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

Выделиться и сформулировать оригинальную и уникальную точку зрения никто не запрещает.

Но у этой тактики есть два главных минуса:

• Дополнительных баллов за оригинальность ответа никто давать не будет. Оценивается форма, а не уникальность мысли.

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

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

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

Вот пример хорошего и слабого ответа на вопрос It is better for students to work before their university study. Do you agree or disagree?.

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

Ясно, что первый ответ получит минимальный балл, а второй высокий.

5. Акцент не важен важно произношение

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

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

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

У каждого из них свои особенности произношения слов.

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

К примеру, возьмем слово chaos хаос. Русскоговорящему человеку очень хочется прочитать его именно как [хаос]. Но это будет уже ошибкой, потому что правильный вариант [ke.s].

Или другой пример слово bear (медведь). В американском английском оно произносится как [ber], в английском [be(r)]. Но если сказать [br], то медведь волшебным образом превратится в пиво. И за это снимут баллы.

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

***

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

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

Онлайн-школа EnglishDom.com вдохновляем выучить английский через технологии и человеческую заботу

Только для читателей Хабра первый урок с преподавателем в интерактивном цифровом учебнике бесплатно! А при покупке занятий получите до 3 уроков в подарок!

Получи целый месяц премиум-подписки на приложение ED Words в подарок. Введи промокод 5ielts на этой странице или прямо в приложении ED Words. Промокод действителен до 05.03.2021.

Наши продукты:

• Учи английские слова в мобильном приложении ED Words

• Учи английский от А до Z в мобильном приложении ED Courses

• Установи расширение для Google Chrome, переводи английские слова в интернете и добавляй их на изучение в приложении Ed Words

• Учи английский в игровой форме в онлайн тренажере

• Закрепляй разговорные навыки и находи друзей в разговорных клубах

• Смотри видео лайфхаки про английский на YouTube-канале EnglishDom

Сомнения

Сегодня, пока я работал, возник хороший вопрос:

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

Например, в реализации api-machinery Kubernetes мы можем увидеть функцию со следующей сигнатурой:

func ConvertSlicestringTostring (input * [] string, out * string, s conversion.Scope) error

И в примере очередей с приоритетом мы снова можем найти нечто подобное:

func (pq * PriorityQueue) Pop () interface {};

Разве срезы уже не являются указателями на хранимые в нем данные?

Давайте немного разберемся, используя Go-Playground, чтобы проверить поведение кода.

Во время всего объяснения я буду использовать один и тот же пример: функция, которая инициализирует срез, передает его в качестве аргумента второй функции, изменяет его, а затем печатает срез для проверки содержимого.

Принято считать, что срезы передаются по ссылке. В следующем примере, на самом деле, будут напечатаны [b, b]и [b, b] даже если срез был инициализирован как [a, a], поскольку он был изменен во время выполнения анонимной функции, и изменение видно в main.

func main() {    slice:= []string{"a","a"}        func(slice []string){        slice[0]="b";        slice[1]="b";        fmt.Print(slice)    }(slice)    fmt.Print(slice) }

Использование указателей приводит к тому же по сути результату:

func main() {    slice:= []string{"a","a"}     func(slice *[]string){        (*slice)[0]="b";        (*slice)[1]="b";         fmt.Print(*slice)    }(&slice)    fmt.Print(slice) }

Этот код также напечатает [b, b]и [b, b] Поэтому передача по указателю выглядит бесполезной, и кажется, что срез все равно передается по ссылке, а содержимое изменяется в обоих случаях.

Так почему же у этих функций такая сигнатура?

Объяснение

Вы можете примерно представить реализацию среза так:

type sliceHeader struct {    Length        int    Capacity      int    ZerothElement *byte}

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

Однако имейте в виду, что если указатель будет перезаписан или изменен (из-за копирования, присвоения или добавления), никакие изменения не будут видны вне функции, более того, никакие изменения длины или емкости не будут видны для исходной функции.

Таким образом, ответ на вопрос прост, но он скрыт внутри реализации самого среза:

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

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

Когда мы передаем срез функции в качестве аргумента, значения среза передаются по ссылке (поскольку мы передаем копию указателя), но все метаданные, описывающие сам срез, являются просто копиями.

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

Например, если под срез снова происходит выделение памяти, то используется новое место в памяти; даже если значения совпадают, срез указывает на новое место, и поэтому никакие изменения значений не будут видны, поскольку срезы указывают на два разных места (указатель в копии среза был перезаписан).

Следовательно, в том же примере, но с принудительным повторным выделением среза будут напечатаны [b, b, a]и [a, a] Переместив append()ниже в место после манипулирования срезом, мы можем заметить, что поведение отличается, поскольку срез был перераспределен после манипуляции значениями, а указатель все еще указывает на начальный адрес памяти.

func main() {    slice:= []string{"a","a"}     func(slice []string){        slice= append(slice, "a")        slice[0]="b";        slice[1]="b";         fmt.Print(slice)    }(slice)    fmt.Print(slice) }

Проверим это на коде ниже:

func main() {    slice:= []string{"a","a"}     func(slice []string){        slice[0]="b";        slice[1]="b";         slice= append(slice, "a")        fmt.Print(slice)    }(slice)    fmt.Print(slice) }

Он печатает [b, b, a]и [b, b]по объясненным выше причинам.

Такое поведение может привести к трудно обнаруживаемым ошибкам, поскольку результат зависит от размера исходного массива, например, следующий код:

func main() {    slice:= make([]string, 2, 3)     func(slice []string){                slice= append(slice, "a")                slice[0]="b";        slice[1]="b";         fmt.Print(slice)    }(slice)    fmt.Print(slice) }

Напечатает [b, b, a]и [b, b] поскольку на массив больше не происходит выделение памяти и указатель остается прежним.

Однако при добавлении еще одной строки slice = append (slice, a, a) под массив снова выделяется память, и результатом будет [b, b, a, a]и [](пустой массив, поскольку он не был инициализирован).

Выявить такие ошибки среди сотен или тысяч строк может быть довольно сложно.

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

Теперь вы готовы понять, что выведет следующий код:

func main() {    slice:= make([]string, 1, 3)      func(slice []string){        slice=slice[1:3]        slice[0]="b"        slice[1]="b"        fmt.Print(len(slice))        fmt.Print(slice)    }(slice)    fmt.Print(len(slice))     fmt.Print(slice)}

Можете запустить код на GoPlayground или написать ответ в комментариях.

Английский язык постоянно меняется. Это средство коммуникации и оно постепенно трансформируется в угоду удобства людей, которые на нем говорят.

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

Двойное отрицание

В русском языке двойное отрицание считается стандартной нормой и фраза Я ничего не слышу звучит вполне себе естественно и грамматически правильно.

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

Давайте сразу на примере.

I didnt see nothing.

Didnt это отрицание глагола, а nothing отрицание объекта. Но если следовать грамматике, то перевести фразу как Я ничего не видел нельзя. Правильный вариант Я видел что-то, что в контексте звучит довольно странно.

Чтобы грамматически правильно сказать Я не видел ничего, нужно использовать только одно отрицание: I didnt see anything или I saw nothing.

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

Сегодня это правило игнорируется практически полностью. В разговорном английском двойное отрицание встречается довольно часто и только для усиления.

Если нейтив говорит I didnt see nothing, то это означает Я ничего не видел. Точно так же, как и в русском.

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

В качестве музыкального примера вспомним песню группы The Rolling Stones Satisfaction. Обратите внимание на фразу I cant get no satisfaction Я не могу получить никакого удовольствия.

Предлог в конце предложения

Некоторые грамматически правильные предложения в английском кажутся для студентов очень странными и неестественными.

Сравните два предложения:

Which journal was your article published in?

In which journal was your article published?

В каком журнале опубликована твоя статья?

Штука в том, что именно второе считается грамматически правильным. Но для многих студентов начинать предложение с предлога еще более странно, чем заканчивать им.

Причина в том, что многие студенты еще в школе запоминают, что вопрос должен начинаться с вопросительного слова. Это настолько глубоко вбивается в память, что частные случаи вроде To whom should I give this thing? (Кому мне стоит отдать эту штуку?) кажутся ошибочными.

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

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

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

Вопросы без do

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

Всего существует пять типов вопросов, но нас интересует только один из них общие. На них можно ответить Да или Нет.

А чтобы вспомнить все пять типов вопросов и правила, по которым их грамотно строить, смотрите вот это видео:

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

Do you like this pie? Тебе нравится этот пирог?

По самой форме предложения уже ясно, что это вопрос. Прочитать его иначе невозможно.

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

You like this pie?

Или можно даже короче: Like it?. Если вопросительная интонация есть, то вопрос будет понятным даже в такой форме.

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

Fewer и less

По нормам английского языка fewer нужно использовать вместе с исчисляемыми существительными (к примеру, friends, animals, books, rooms), а less с неисчисляемыми (money, rice, water).

Это правило было описано еще в 1770 году в словаре Мерриам-Вебстер:

As far as we have been able to discover, the received rule originated in 1770 as a comment on less: "This Word is most commonly used in speaking of a Number; where I should think Fewer would do better. 'No Fewer than a Hundred' appears to me, not only more elegant than 'No less than a Hundred', but more strictly proper."

Насколько нам удалось обнаружить, принятое правило возникло в 1770 году как комментарий к слову less: Это слово чаще всего используется, применимо к количеству, где я считаю, что fewer подошло бы лучше. No Fewer than a Hundred кажется мне не только более элегантным, чем 'No less than a Hundred', но и более правильным.

Замечания Бейкера, редактора словаря, относились к его собственному мнению, но со временем их возвели в абсолют. Если можно посчитать fewer, если нельзя less. Это правило все еще остается нормой языка и в официальных документах нужно писать именно так.

Сегодня же существует еще одно правило, более разговорное и упрощенное, по которому less используется с единственным числом, а fewer с множественным. И как можно заметить, эти два правила противоречат друг другу.

По факту получается, что нейтивы используют fewer и less в предложениях как попало. И очень часто fewer просто остается не у дел, а less пихается абсолютно везде.

Less money, less problems. Меньше денег меньше проблем.

Типичная неправильная фраза. Потому что грамматически верный вариант должен быть Less money, fewer problems. Но в качестве разговорного вполне рабочая и понятная схема.

Me как субъект предложения

У английских местоимений есть только два падежа: именительный и объектный. И по правилам языка только именительный падеж может быть подлежащим.

I went to the park last Sunday. Я ходил в парк в прошлое воскресенье.

Соответственно, обжектив может быть только дополнением.

What do you want from me? Что ты от меня хочешь?

Но с составным подлежащим правило часто дает сбой. Допустим, у нас есть рассказчик (I) и его друг (Jack). По правилам английского в составном подлежащем рассказчик должен назвать сначала друга, а потом себя:

Jack and I went to the cinema. Джек и я пошли в кино.

Но в разговорном варианте оно часто трансформируется в:

Me and Jack went to the cinema.

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

Бывает даже следующий вариант:

Me and him went to the cinema.

Сразу два объектных падежа в качестве подлежащего вместо классических He and I. Или можно привести еще более естественный вариант: You and me. К примеру, You and me should go to the cinema Ты и я должны сходить в кино. Среди нейтивов не так много людей, которые скажут здесь You and I даже несмотря на то, что это абсолютно правильно грамматически.

***

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

Онлайн-школа EnglishDom.com вдохновляем выучить английский через технологии и человеческую заботу

Только для читателей Хабра первый урок с преподавателем в интерактивном цифровом учебнике бесплатно! А при покупке занятий получите до 3 уроков в подарок!

Получи целый месяц премиум-подписки на приложение ED Words в подарок. Введи промокод may_21 на этой странице или прямо в приложении ED Words. Промокод действителен до 01.07.2021.

Наши продукты:

• Учи английские слова в мобильном приложении ED Words

• Учи английский от А до Z в мобильном приложении ED Courses

• Установи расширение для Google Chrome, переводи английские слова в интернете и добавляй их на изучение в приложении Ed Words

• Учи английский в игровой форме в онлайн тренажере

• Закрепляй разговорные навыки и находи друзей в разговорных клубах

• Смотри видео лайфхаки про английский на YouTube-канале EnglishDom