Anton Fedorov datacompboy

Приходилось ли вам запинаться в работе? Вот берёте таск: зафигачить красивый отсчитыватель времени "До конца супер предложения осталось всегда 2 часа". Открываете редактор… и щёлк: а как делать-то? Вроде я что-то слышал, что мы лэндинги начали на Vue делать. Или тут еще реакт?

Хорошо, когда вы в опенспейсе сидите через два стола. Всегда можно встать, и тихо спросить соседа "Напомни, мы Vue для всех теперь берём?". Хуже, если ТЛ в другом часовом поясе. Тот же вопрос — но ответ завтра. А если он закрутился, то послезавтра. И всё, вместо 1 минуты — двое суток задержки.

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

There are a lot of posts about what a typical coding interview at Google looks like. But, while not as widely described and discussed, there is also quite often a system design interview. For an SRE position it’s NALSD: non-abstract large system design. The key difference between SWE and SRE interviews consists in these two letters: NA.

So, what is the difference? How to be prepared for this interview? Let’s be non-abstract, and use an example. To be more non-abstract, let’s take something from the material world, such that you won’t be asked the exact same thing at the real interview (at least, not at the Google interview) :)

So, let’s design a public library system. For the paper books, like you have seen everywhere around. The whole text below was written all at once within around one hour, to roughly show you the areas that you should be able to cover / touch during the interview. Please excuse some disorder, that’s how I think (therefore I am).

Я описывал ранее типичное кодинг-интервью. Помимо кодинга почти всегда есть вопрос на проектирование систем. (Large) System Design. В случае собеседований на SRE, это еще более интересный (как по мне) зверь — NALSD. Non-abstract large system design. Главное отличие между SWE и SRE именно в этих буковках “NA”.

В чем же отличие, и как подготовиться к нему? Давайте разберём на примере. В качестве примера возьмём что-то весьма материальное, что-то такое, что точно никто никогда не спросит на реальном собеседовании (в гугл) :)

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

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

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

Нет, я не стал рекрутером. Процесс собеседования предполагает сперва разговор с рекрутером. Это общая беседа “что-куда-зачем” (то есть описание процесса для вашего конкретного случая) и тот самый всеми любимый скрининг из опросника с несколькими вариантами ответов. Скрининг мне в своё время показался весьма базовым, подозреваю, что вы отвечали на такие вопросы уже сотню раз. Затем собеседования будут проводиться уже инженерами — вашими будущими коллегами (близкими или далёкими, это уже как получится, наша планета весьма небольшая).

Кэш глазами «чайника»:


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

Давайте прокрутим полный оборот ситуаций.

Tl;dr: добавляя в архитектуру кэш важно явно осознавать, что кэш может быть средством дестабилизации системы под нагрузкой. Смотрите конец статьи.

TL;DR: В ближайшее время можно будет оставлять комментарии на YouTube без Google+ аккаунта.

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

И снова доброе утро для всех пользователей облачных продуктов!

С 18 мая 2015 вычисления и запуск продуктов в Google Compute Engine стали еще выгоднее:

• Снижены цены на облачные инстансы (Google Compute Engine Instance):
• Появился новый тип «вытесняемых» (preemptive) инстансов, которые можно использовать для пакетной обработки данных в течение короткого времени по очень низкой фиксированной цене.

Рекурсия: см. рекурсия.

Все программисты делятся на 11₂ категорий: кто не понимает рекурсию, кто уже понял, и кто научился ею пользоваться. В общем, гурилка из меня исключительно картонный, так что постигать Дао Рекурсии тебе, читатель, всё равно придётся самостоятельно, я лишь постараюсь выдать несколько волшебных пенделей в нужном направлении.

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

— Как она сложена?
— Превосходно! Только рука немного торчит из чемодана.

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

  def fib(n):
    if n<0: raise Exception("fib(n) defined for n>=0")
    if n>1: return fib(n-1) + fib(n-2)
    return n

приходится городить всевозможные грязные хаки, начиная от:

  @memoized
  def fib(n):
    if n<0: raise Exception("fib(n) defined for n>=0")
    if n>1: return fib(n-1) + fib(n-2)
    return n

И заканчивая вообще:

  def fib(n):
    if n<0: raise Exception("fib(n) defined for n>=0")
    n0 = 0
    n1 = 1
    for k in range(n):
      n0, n1 = n1, n0+n1
    return n0

Расскажи мне полуправду, как полуэльф полуэльфу...

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

Ни в коей мере не считая себя чем-то выдающимся (ну, разве что, пузом), решил ответить на вопросы «а как там?» и «а почему туда?» хоть и субъективно, но максимально объективно и, по возможности, информативно.

Если какая-либо операция превращается в рутину — автоматизируй её. Даже если времени потратишь больше — зато ты занимался не рутиной, а интересным делом. Именно под этой вывеской вместо того, чтобы просто запатчить новые 11 версий rtsp_streamer'а для камер от TopSee, решил нарисовать автопатчер. Идеальным языком для любых наколенных изделий я считаю питон — достаточно лаконично, достаточно жестко по читабельности (хотя я всё равно умудряюсь сделать его не читаемым). В общем, сейчас я расскажу, как с помощью палки и верёвки за один вечер научиться рисовать автопатчеры.

Глупо спорить с тем, что аналоговое видеонаблюдение уходит в прошлое: дешевые IP камеры дают картинку сопоставимого качества с дорогими аналоговыми. Помимо этого, IP камеры не ограничены сверху ничем, кроме производительности регистратора, тогда как аналоговые камеры требуют жесткого соответствия приёмной карты, согласования уровней сигнала передатчиков/усилителей/приемников и прочего шаманства.
Конструируя систему на базе IP камер в любой момент можно снять камеру и заменить на более качественную — если при этом сохранить IP адрес и логин-пароль, то, скорее всего, даже не придётся менять настройки приемника — просто в архив пойдёт более качественная картинка.
С другой стороны, это накладывает ограничения на регистратор — он должен быть готов работать с любым разрешением, любым битрейтом, любым кодеком и любым протоколом… Ну или по крайней мере, корректно работать с заявленным.

В мире софта есть два пути — есть linux-way: это набор небольших программ, каждая из которых делает одну функцию, но очень хорошо; и есть windows-way: это огромные кухонные комбайны, которые умеют делать всё, и немного больше. Главная проблема linux-way — это отсутствие интерфейса. Чтобы получить всю пользу придётся скурить маны (или хотя бы прочитать --help), и поэкспериментировать. А так же сообразить, что и с чем можно скомбинировать и как. Главная проблема windows-way — это потеря основной функции. Очень быстро при обрастании доп.функционалом теряются тесты ключевого функционала, и со временем начинаются проблемы даже с ним. А еще при этом начинается инерция мышления: «это главная функция, она оттестирована сильнее всего, там бага быть не может, пользователь делает что-то не то».

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

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

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

Как известно, телефония предполагает передачу голоса. Для передачи голоса полная полоса 20Гц-20кГц никому не нужна, для четкого различимого и узнаваемого голоса вполне достаточно до 3.5кГц. Если быть точнее, речевая полоса частот используемая в телефонии от 300 до 3400Гц. При компрессии в общий канал, для точного выделения нужны защитные интервалы частот по краям, потому полоса пропуския — 4кГц. При оцифровке это получается 8кГц. Сейчас, в связи с развитием толщины каналов связи, те же скайпы и прочие, хвастающиеся «повышенным» качеством, используют 16кГц, а то и 32кГц, что, впрочем, реально на слух практически не отличимо при обычном разговоре (зато очень хорошо различимо при ухудшении качества канала связи, но когда это волновало маркетолухов).

Итак, практически все звуковые файлы, которые используются в телефонии, записаны с 8кГц оцифровкой. Для ускорения обработки больших потоков, применяемые методы сжатия так же просты и направлены на достойный результат при применении к желаемому — сжатию речи. Это простая оцифровка (PCM), простые дельта-кодеки (ADPCM, G711), либо хитрые кодеки (GSM 06.10). Эти форматы являются «родными» для систем телефонии — asterisk, freeswitch (и наверняка других тоже). В этих форматах данные подготавливаются для проигрывания системой людям, в эти же форматы системы могут записывать записи.

Однако сейчас всё шире web шагает по планете, и людям хочется иметь возможность прослушать записи разговоров, приветствий и др. на вебе, где «родным» форматом стал mp3…

Итак, у нас есть задача: пофиксить баг, производитель от которого открещивается, клиенты не замечают, а жить хочется. Есть камера, поток от неё на UDP просто адово ломается, поток на TCP работает, но постоянно рвутся коннекты (и при каждом обрыве пропадает 3-5 сек видео). Виновны в проблеме все (и камера и софт), но обе стороны утверждают что у них всё зашибись, то есть ситуация обычная: ты баг видишь? нет. А он есть.

Недавно я уже поднимал волну о баге TCP стриминга камер, но тогда я её катил исключительно на китай. А проблема куда как шире. Для себя я проблему решил, страждущим выкладываю прошивки с фиксом.

А теперь садитесь поудобнее, я поведаю вам об этом баге подробно.

Недавно на хабре публиковались статьи о openvz и lxc. Это напомнило мне, что эта статья всё еще валяется в sandbox'е…

Для целей размещения проектов я применяю такую схему: каждый сервис запускается в изолированной среде: боевой — отдельно, тестовый — отдельно, телефония — отдельно, веб — отдельно. Это снижает риски взлома систем, позволяет бакапить всё и вся одним rsync'ом на соседний сервер по крону, а в случае слёта железа просто поднять на соседнем железе. (А использование drbd + corosync позволяет это делать еще и автоматически)

Для создания изолированной среды есть два подхода, именуемые VDS (виртуализация аппаратуры) и VPS/jail (виртуализация процессного пространства).

Для создания VDS изоляций применяют XEN, VirtualBox, VMWare и прочие виртуальные машины.
Для создания VPS на linux используется либо linux-vserver, либо openvz, либо lxc.

Плюсы VDS: система внутри может быть совершенно любой, можно держать разные версии ядер, можно ставить другую ОС.
Минусы VDS: высокие потери производительности на IO, избыточное потребление CPU и RAM на сервисы, дублирующие запущенные на серверной ОС.

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

Так как мне не нужны разные ОС, то всюду применяю linux-vserver (так уж сложилось исторически, применяю с 2004го года, а openvz вышел в открытый доступ в 2005м), а lxc в моём понимании еще не дорос до продакшена (хотя и очень близок уже).

Приведу цитату из FAQ:
«What is the status of Linux-VServer?
Linux-VServer has more than a decade of maturity and is actively developed. Two projects are similar to Linux-VServer, [LXC], and [OpenVZ]. Of the two, OpenVZ is the more mature and offers some similar functionality to Linux-VServer. LXC is solely based on the kernel mechanisms such as cgroups that are present in modern kernels. These kernel mechanisms will continue to be refined and isolation will mature. As that occurs, Linux-VServer will take advantage of those new features separately from LXC and continue to provide the same robust user interface that it does currently. Currently, LXC offers significantly less functionality and isolation than Linux-vserver. LXC will eventually be a robust wrapper around kernel mechanisms but is still under heavy development and not considered ready for production use.»

Ниже я опишу базовые операции по запуску LAMP сервера в изолированном окружении.

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

Итак, началось всё с малого — простенькая купольная камера, бралась самая паршивая по принципу "только б IP и купол". После пошел процесс перебора софта (тема отдельного поста, будет, опять же, позже)… В конце зафиксировался на Macroscop в один канал. Стояла пару месяцев, есть-пить не просила, наркоманов гонять помогала.

И вот работает вроде всё, но как-то подлагивает периодически. Грешил на всё: на проц, на сеть, на софт, на погоду на марсе… Саппорт по логам говорит, что-де камера периодически отваливается.

Upd

I. Постановка задачи

Нужно держать температуру на заданном неком уровне и менять задание. Есть микроконтроллер, к которому прицеплены измеритель температуры, и симистор для управления мощностью. Не будем греть голову на ТАУ, ни разностными схемами, просто возьмём и сделаем «в лоб» ПИД-регулятор.

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

Несмотря на свою простоту как физического смысла, так и математической записи:

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

Причем проверить качество реализации ПИД регулятора крайне легко.

Прекрасный сервис помощи с лечением в тяжелых случаях от Лаборатории Касперского kaspersky-911.ru, почил в бозе.

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