Архив за месяц: Сентябрь 2020

Восстановление данных в современной инфраструктуре: как один админ бэкапы настраивал

Опубликовано автором
Ответить

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

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

Я не буду говорить о себе, а расскажу чужую историю. Все имена в ней выдуманные, а совпадения — случайны. Её главный герой — человек по имени Савелий. И, по случайному совпадению, он админ, как и я.

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

Из этой статьи вы узнаете об эволюции взглядов Савелия: как с усложнением инфраструктуры менялся его подход к бэкапам и к каким выводам он пришёл. Я рассказывал об этом на прошлогоднем HighLoad++, а сегодня делюсь текстом по мотивам доклада.

Глава 1, в которой Савелий полагается на систему управления конфигурациями

Наш Савелий жил-поживал и продолжал изучать материалы по Linux — даже на работе. И однажды он узнал, что существуют системы управления конфигурациями: Ansible, Puppet, Chef и им подобные. Они избавляют от ручной работы при подготовке сервера ко вводу в эксплуатацию. 

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

Со временем инфраструктура проекта усложнилась.

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

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

Сервисы также изменились: их стало больше, появились связи и зависимости. 

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

Так Савелий отказался от бэкапов.

Глава 2, в которой появляется карта расположения сервисов

Савелий работал в компании не один, с ним было много программистов. Один из них — Аристофан — был его добрым другом. 

Однажды, работая с базой данных, Аристофан случайно сделал дроп. 

Савелий — хороший админ. Когда он настраивал репликацию, то следил за отставанием от мастера. Точнее он его не допускал. 

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

Что тут сказать: такое бывает не только в сказках. 

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

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

  1. Он должен находиться в стороне и не должен быть подвержен изменению. 

  2. Он обязательно должен восстанавливаться. 

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

После того как Савелий сформулировал эти правила, появился другой вопрос. Как правильно поступать: по старинке бэкапить сервер целиком или же делать именно сервисные бэкапы?

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

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

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

Процесс восстановления в таком случае мог пойти по двум сценариям:

  1. Восстановить весь бэкап сервера и потом взять нужные данные. Минусы:

    1. увеличение нагрузки на сеть;

    2. увеличение нагрузки на устройство хранения;

    3. увеличение времени на выборку нужных данных из общей кучи.

  2. Выбрать вручную только те данные, которые нужно восстановить. Минусы:

    1. увеличение времени на выборку нужных данных из общей кучи;

    2. высокая вероятность того, что будут выбраны не все данные и процедуру придётся повторить (опять-таки потраченное время).

Как видно, оба варианта имеют существенные недостатки.

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

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

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

Вывод, к которому пришёл Савелий, прост: современным бэкапам — современную оркестрацию. 

Глава 3, в которой Савелий понимает, что серверы созданы не только для того, чтобы их бэкапить (а голова не только для того, чтобы в неё есть) 

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

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

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

Минусы:

  • формирование инкрементального бэкапа на клиенте в некоторых случаях более затратно с точки зрения ресурсов, так как нужно вычислять разницу «было-стало»; 

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

Плюсы:

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

  • экономия места в хранилище.

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

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

В общем, Савелий — молодец.

Глава 4, в которой появляется devel

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

Проблема была в том, что devel — это территория разработчика, вотчина Аристофана. Но Савелий понимал, что рано или поздно Аристофан придёт к нему с вопросом, а есть ли у него бэкап данных за какой-то день. 

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

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

Как Савелий организовал процесс бэкапа виртуальных машин: 

  1. На момент начала бэкапа виртуальной машины на ней не должно быть снапшотов.

  2. Если на виртуальной машине есть снапшот, сделанный вручную Аристофаном, то:

    • не удалять снапшот;

    • не выполнять бэкап;

    • сообщать об этом Аристофану и уточнять, нужен ли ему ещё снапшот, и действовать в зависимости от его ответа.

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

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

Почему Савелий не бэкапил виртуалки с базами данных? На самом деле всё просто: теперь он всегда бэкапит все инстансы с базами данных. По умолчанию. Потому что он помнит прекрасную историю про дроп. А на машинах с базами данных ничего ценного, кроме самих данных в базе (для всего остального есть Puppet!), нет.

Глава 5, в которой появляются отличия бэкапа базы данных от бэкапа сервиса 

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

С этим столкнулся и наш герой. Он начал использовать pipe: подключался к базе — и на лету сливал данные в удалённое хранилище. Причём даже в тех случаях, когда места на сервере хватало. Савелий принял решение бэкапить везде одинаково, чтобы не было энтропии. Админы довольно быстро понимают плюсы такого подхода, а кто не понимает, тот рано или поздно тонет в «костылях» («костыль» в данном случае — это использование разных подходов к решению одной и той же задачи). 

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

Поэтому Савелий разрешил Аристофану:

  • включать и выключать бэкап;

  • менять параметры утилит бэкапа;

  • менять расписание бэкапа.

К реализации Савелий подошёл просто: он периодически формировал список со всеми машинами с базами данных и делал приоритизацию. Для чего в данном случае понадобилась приоритизация? Всё просто — давайте представим себе ситуацию, когда нужно выполнить бэкап большого объема данных в условиях того, что этот большой объем расположен на большом количестве серверов? Очевидные проблемы, которые могут возникнуть при данных условиях:

  • устройство хранения может стать узким местом, так как сеть не резиновая (источников много, а устройство хранения — одно)

  • как только возникает ограничение пропускной способности — происходит увеличение времени бэкапа для тех серверов, которые бэкапятся

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

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

Глава 6, в которой Савелий не может жить без уведомлений

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

Но всё оказалось не так просто. 

Савелий решил проверить по метрикам, как ведёт себя сервис. Когда приходит бэкап, не начинает ли он, например, отвечать медленнее?

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

Появляется сразу несколько проблем. Главная — в бэкап уезжает мусор, так как данные не записались на диск целиком.

Последствия этого:

  • тратится место в хранилище;

  • потребляются ресурсы сети;

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

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

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

Всё сделано, все бэкапится. Савелий научился выявлять пересечения и составлять расписание. 

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

Как об этом узнать? 

Глава 7, в которой необходимо проверять бэкап

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

Шаг № 1

Проверяется статус: бэкап завершился со статусом «ОК» или произошла ошибка. Если ошибка, то разбираемся почему. Если «ОК», переходим к следующему шагу. 

Шаг № 2

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

Шаг № 3

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

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

Шаг № 4

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

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

Глава 8, в которой появляется реализация бэкапов с помощью Bareos 

Как в каждой правильной сказке, в конце Савелий должен был изобрести свою систему бэкапов, которая удовлетворяла бы всем его требованиям. На этом можно было бы закончить историю словами «И жили они долго и счастливо!», но не тут-то было. Жизнь не сказка: работа сама себя не сделает, как и система бэкапов по щелчку из воздуха не появится.

На момент выбора решений было не то чтобы очень много:

  • коммерческие системы резервного копирования (чаще всего на них не хотят тратиться);

  • AMANDA;

  • Bacula;

  • возможно, было что-то ещё, но про это уже никто не помнит.

Савелий решил действовать по хардкору: начал использовать Bacula, а позже —  Bareos (форк Bacula). Он никогда не искал лёгких путей. 

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

Совет № 1

Используйте virtual changer (VC). Это не какой-то конкретный инструмент, а целый класс утилит.

Для примера представьте набор сервисов, который мы бэкапим в два пула. Один пул называется SOMETHING-full, второй — SOMETHING-incremental. В этом случае можно бэкапить данные в два пула и не переживать о том, что пачка заданий, ожидающих полного бэкапа, встанет в очередь, пока не закончатся инкрементальные бэкапы. Это довольно часто бывает нужно. 

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

Совет № 2

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

Если вы имеете дело с отдельным блочным устройством, экспериментируйте с параметром read ahead. Конечно, всё зависит от того, хватит ли памяти на машине, но в случае восстановления это достаточно сильно помогало Савелию. 

Совет № 3

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

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

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

Совет № 4

В Bareos много собственных параметров и крутилок. Крутить можно всё что угодно. Основное, на что Савелий обращает внимание:

  • параметры, которые относятся к Maximum Volume Jobs и Concurrent Jobs, — как раз для настройки количества заданий на кассете; 

  • параметры, которые касаются block size и file size, влияют на скорость записи бэкапа, если их можно откуда-то линейно быстро читать и быстро писать; 

  • параметры, которые дадут чуть больше гарантий того, что будет корректная цепочка бэкапов Max Full Interval;

  • параметры, которые остановят выполнение задачи, если нет подходящей кассеты Max Wait Time;

  • параметры Spool Attributes и Spool Data относятся больше к ленточному бэкапу, чем к файловому, но Савелий считает, что имеет смысл их тоже покрутить. 

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

Совет № 5

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

  • Full: два последних успешных бэкапа (делается один раз в неделю);

  • Incremental: всё до самого старого Full (делается один раз в сутки).

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

Если нужно хранить дольше, то с этим нужно что-то делать, например бэкапить базы или сервисы дополнительно в другие пулы. Но более правильным решением будет использование copy job (migration, если не хочется занимать в два раза больше места), которая заберёт то, что уже лежит в системе хранения, положит в другой пул — и оно будет там жить столько времени, сколько нужно. 

Совет № 6

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

Нужно искать другие варианты решения, например:

  • бэкапиться снапшотом;

  • делать бэкап через pipe.

Или рассмотреть вариант не бэкапить Bareos по классической схеме File daemon -> Storage daemon, а придумать другую систему, которая будет заливать необходимые файлы в хранилище. Если выбран такой вариант, то его стоит обозначить как задачу с пустым fileset в Bareos. Нужно это для того, чтобы сведения обо всех бэкапах находились в одном месте.

Совет № 7

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

Совет № 8 

Проверяйте базу Bareos: bareos-dbcheck в помощь. Обратите внимание на DB backend: MySQL, PostgreSQL. Как минимум стоит принять во внимание мнение разработчиков по данному вопросу, чтобы потом не удивляться.

Совет № 9 

Собирайте логи и метрики: в Elasticsearch, InfluxDB, Prometheus — на ваш вкус. Они помогут ответить на кучу вопросов, а при построении бэкапа они возникнут абсолютно точно. 

Приблизительно такие графики можно строить, собирая различные метрики:

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

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

Также будут видны попытки что-то ресторить. 

Там, где график идёт вверх и скорость увеличивается, меняли параметр read ahead. В данном случае это изменение стандартного read ahead для блочного устройства. 

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

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

Начало работ:

Окончание и результаты работ:

Работы, завершённые с ошибками:

Выводы 

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

Как бы ни менялся мир вокруг, какие бы технологии ни появлялись, данные — это основная ценность проекта. Поэтому кто бы когда бы и что бы ни говорил, бэкапы нужны всегда. Бэкапы важны!

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

Не надо бояться экспериментировать. Хотя Bareos по своей сути довольно консервативен, всегда можно прикрутить что-то сбоку, чтобы сделать возможным и эффективным его использование в современных инфраструктурах. Рано или поздно всё точно получится. Савелий смог — и вы сможете!

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

ссылка на оригинал статьи https://habr.com/ru/company/badoo/blog/521442/

Топ IT-книг прошлого века, которые актуальны до сих пор

Опубликовано автором
Ответить

«Физические законы — это не Python, их не изменить в новых версиях, то есть материал в книге (по электронике) будет актуален всегда».

ne555, из комментариев на Хабре

image

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

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

Вдохновившись историей «второго рождения» учебника по электронике 1979 года (а точнее, комментариями к ней), мы решили собрать для вас подборку книг по электронике, которым в 2020 году исполнилось от 25 до 69 лет, но которые при этом не утратили своей актуальности. А чтобы не ограничиваться собственными нейтрально-редакторскими вводными, мы попросили прокомментировать эту подборку победителя «ТехноТекста-2019» в номинации «Научно-популярное», старожила Хабра, разработчика интегральных микросхем для космоса и потомственного инженера Валерия Шункова aka @amartology.

Осторожно: прочтение книг из этой подборки может вызвать острое желание взяться за паяльник. Вдохновляйтесь, творите и делитесь своим опытом с Хабром, ведь именно по просьбе сообщества мы добавили в список номинаций «ТехноТекста-2020» новую — «Железо и его разработка».

I. «Юный радиолюбитель», Виктор Гаврилович Борисов (1951)

image

Для кого: рассчитана в первую очередь на детей школьного возраста.

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

Коротко о книге и её создателе:

Виктор Гаврилович Борисов — советский радиоконструктор и журналист. Он родился в Москве в 1915 году, с детства интересовался математикой и физикой, а потому образование решил получать в строительном техникуме по направлению «Радиоинженерия». В годы Великой Отечественной войны служил радистом на торпедном катере, получил орден Отечественной войны II степени и множество медалей.

После войны Борисов работал на Центральной станции юных техников (ныне Федеральный центр технического творчества учащихся), где занимался с юными радиолюбителями, для просвещения которых он и стал заниматься литературным творчеством. На протяжении 40 (!) лет он публиковал книги и статьи о радиотехнике, также возглавлял отдел «для начинающих радиолюбителей» журнале «Радио». Самая известная книга Борисова — «Юный радиолюбитель» — выдержала восемь прижизненных переизданий, последнее из которых было выпущено в 1992 году.

Виктор Гаврилович ушёл из жизни в 2007 году в возрасте 92 лет за пару дней до Дня радио, которому он посвятил всю свою жизнь.

Мнение amartology:

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

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

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

Книга предназначена для детей, причём именно для детей, даже не подростков. И, как и любая советская детская книга, написана очень специфическим языком, который лично меня, живущего в 2020 году взрослого, изрядно раздражает. Впрочем, рекомендовать книгу детям тоже довольно сложно, потому что ключом к её полувековой популярности было постоянное обновление и актуализация содержимого с каждым новым изданием, а за 30 лет с 1992 года довольно многое успело измениться. Например, в рассказе про частоты было бы крайне уместно описание 3-4-5G, а не только более традиционных диапазонов, массовое использование которых прекратилось вместе с закатом радиолюбительства.

То, что материал в книге по электронике будет актуален всегда, — это, конечно, неправда. Он будет всегда правдив, но актуальность — это совсем другое. Вот, например, первые издания «Юного радиолюбителя» описывали технику на лампах, а поздние — на транзисторах. Стал ли материал про лампы менее правильным? Нет. Но он устарел. А сейчас, к сожалению, в значительной степени устарел и материал про транзисторы, ведь в ходу готовые модули и software-defined radio. То же самое касается и других фундаментальных книг по электронике: ключ к из долгой жизни — регулярные переработки и новые издания.

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

II. «Искусство схемотехники», Пауль Хоровиц и Уинфилд Хилл (1980)

image

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

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

О книге и её создателях:

Авторы этого трехтомника — американские физики, инженеры-электроники Пауль Хоровиц и Уинфилд Хилл.

Пауль Хоровиц — PhD, выпускник, а впоследствии профессор Гарварда, где он больше четверти века (с 1974 года) читал курс лабораторной электроники, конспекты с которого впоследствии и легли в основу будущей книги. Он работал в разных областях — в сканирующей микроскопии, в астрофизике и в биофизике. В области практической электроники он изобрёл акустический механизм для обнаружения наземных мин, электронную клавиатуру кода Морзе / Бодо, использующую диодную матрицу, и 66 интегральных схем TTL для использования в любительском радио. Из примечательного — Хоровиц также засветился в SETI (программе по поиску внеземных цивилизаций) и даже считается прототипом одного из героев научно-фантастического романа Карла Сагана «Контакт».

Уинфилд Хилл же является директором лаборатории электронной техники в Институте Роуленда (впоследствии ставшего частью всё того же Гарвардского университета), где сконструировал более 250 электронных и научных приборов. Хилл также является основателем Sea Data Corporation, которая разрабатывает инструменты для глубоководной океанографии и в качестве главного инженера сконструировал около 50 океанографических инструментов. Он участвовал в многочисленных экспериментах в глубоководных районах океана.

Их совместная работа — учебник «Искусство схемотехники» — в 2020 году празднует 40-летний юбилей со дня выхода. Она дважды глобально перерабатывалась самими авторами — второе издание вышло в 1989 году, а третье, совсем новое, — в 2015-м. Сочетание энциклопедичности и наукоёмкости и легкостью языка и доступностью изложения сделали эту работу неофициальной «библией электроники».

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

Мнение amartology:

«А вот эта книга для меня — настольная с третьего курса института и до сегодняшнего дня. Для совсем начинающих она может оказаться сложновата, но лучше её на самом деле не найти. Главное достоинство «Искусства схемотехники» — очень хорошо сбалансированное сочетание теории и практики, с конкретными примерами, советами и рассказами, как обойти типичные узкие места и неидеальности, о которых не пишут в других учебниках.

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

Впрочем, про время ещё кое-что можно сказать.

Во-первых, второе (1989) и третье (2015) издания книги несколько различаются по подходу. Второе — это скорее справочник для инженера, а третье пытается стать полноценным учебником, заменяя часть примеров «домашками» в конце глав. Так что, возможно, стоит иметь оба издания. Плюс есть ещё совсем свежая книга X chapters, в которой собран материал, не попавший в третье издание, — это что-то вроде продвинутого курса.

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

Ничего столь же всеобъемлющего и прекрасного мне в голову не приходит, так что, если вы захотите добавки, могу только порекомендовать смотреть в сторону более глубоких книг по более узким темам, например на двухтомник «Конструирование высокоскоростных цифровых устройств» Джонсона – Грэхема, более известный как «курс чёрной магии».

III. «Полупроводниковая схемотехника», Ульрих Титце и Кристоф Шенк (1980)

image

Для кого: радиолюбителям, инженерам радиотехники и электроники и научным работникам.

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

О книге и её создателях:

«Настольная книга электронщика» авторства двух немецких инженеров, Ульриха Титце и Кристофа Шенка. К сожалению, найти подробную информацию об их учёном статусе и о том, почему они решили создать и опубликовать данный труд, нам не удалось (Может быть, вы знаете больше? Напишите в комментариях.), зато мы нашли множество отзывов читателей.

Ульрих Титце — доцент кафедры технической электроники Университета Фридриха-Александра в Эрлангене-Нюрнберге.

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

image
Авторы книги Гамм, Шенк и Титце на её 40-летии в 2009 году

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

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

Мнение amartology:

«Титце и Шенк — ещё одна моя настольная книга, с которой я познакомился на институтской скамье. Её чуть сложнее рекомендовать широкой аудитории в силу весьма сухого академического стиля и обилия специфики разработки микросхем, а не их применения. Поэтому в качестве первой и основной книги я бы рекомендовал Хоровитца – Хилла, а Титце и Шенка предложил бы читать в качестве дополнения, чтобы лучше понимать, что происходит внутри используемых вами девайсов. Впрочем, и здесь найдётся множество полезных схем и проверенных временем отличных приёмов.

Главный плюс двухтомника Титце и Шенка — полнота и фундаментальность изложения основ очень широкого спектра тем, поэтому, как и в случае в Хоровитцем – Хиллом, в качестве аналога можно порекомендовать только ещё что-то более узкое, глубокое и современное. Но после только того, как вы познакомитесь с этой книгой.

Например, если вам интересно, как устроены микросхемы, подойдёт учебник «Основы микроэлектроники» И. П. Степаненко, которая, кстати, представляет собой глубокую переработку книги «Основы теории транзисторов и транзисторных схем» 1967 года. А если вас интересует цифровая электроника, то… переходим к пятому пункту данного списка.

Главный минус книги Титце и Шенка — то, что в русском и английском (восьмом) издании она двухтомник, а в оригинальном немецком (шестнадцатом) — трёхтомник, да еще и с третьим автором. Советовать оригинал не буду, просто имейте в виду, что в этой книге отлично даны основы, но самое новое и актуальное стоит поискать где-то еще».

IV. «Электронные самоделки», Борис Сергеевич Иванов (1985)

image

Для кого: для школьников 5–8 классов.

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

О книге и её создателе:

Борис Сергеевич Иванов начал публиковаться в научно-популярных СМИ (таких как «Юный техник», «Моделист-конструктор», «Пионер») с 22 лет (с 1958 года) и практически всю свою жизнь посвятил технической журналистике. Более 40 лет (с 1975 года) он проработал в журнале «Радио», где долгое время возглавлял раздел «Радио» начинающим», самостоятельно писал статьи и редактировал чужие опусы. Также более 20 лет был редактором-составителем детского журнала «Мастерок», регулярно выпускал книги, методические пособия и статьи для юных радиолюбителей.

При этом Борис Сергеевич активно сотрудничал с радиокружками, детско-юношескими клубами и Дворцами юных техников, уточнял у педагогов, насколько эффективно строить обучение по его публикациям, по запросу создавал дополнительные методические пособия для удобства юных читателей и их наставников. Его пособия неоднократно издавались и переиздавались не только в России, но и на Украине, в Молдавии, Литве, Латвии, Узбекистане. Он ушёл из жизни в 2015 году, незадолго до своего 80-летия.

На его книгах и брошюрах, таких как «Осциллограф — ваш помощник», «Самоделки юнармейца», «В помощь радиокружку» и «Энциклопедия начинающего радиолюбителя», выросло не одно поколение техноDIYщиков прошлых лет.

Мнение amartology:

«Ещё одна легендарная детская книга. На мой взгляд, она также из тех, кто плохо состарился, и почтенный статус, к сожалению, не делает этот труд актуальнее. Книга — сборник готовых рецептов для юных самодельщиков, начисто лишённый теории. А без понимания того, как и почему работают те или иные схемы, результат общения с книгой будет весёлым, но бесполезным. Да и таким ли он будет весёлым для ребёнка XXI века: точно ли ребёнку будет интересно делать примитивный проводной телефон в век, когда у каждого полно гаджетов?

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

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

V. «Архитектура компьютера и проектирование компьютерных систем», Дэвид Паттерсон, Джон Хеннесси (1994)

image

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

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

О книге и её создателях:

Дэвид Паттерсон — американский учёный в области информатики и разработчик микропроцессоров. Он закончил Калифорнийский университет в Лос-Анджелесе со степенью PhD, какое-то время был в нём деканом факультета компьютерных наук. Также Паттерсон руководил ассоциацией Computer Research, консультировал проект SPARC, а в 2003–2005 годах входил в PITAC (Совет по информационным технологиям при президенте США).

Паттерсон известен в первую очередь своим вкладом в проектирование RISC-процессоров — архитектуры компьютера с сокращенным набором команд (RISC), которая сейчас используется в 99 % новых компьютерных микросхем. Он был руководителем проекта Berkeley RISC, также участвовал в создании принципа работы RAID-массивов и в разработке концепции Network of Workstations. Обладатель множества научных наград, таких как медаль Джона фон Неймана (2000), C&C Prize (2004), премия Эккерта – Мокли (2008) и премия Тьюринга (2017). Последнюю он получил за разработку RISC-процессоров в паре с Джоном Хеннесси.

Джон Хеннесси — бывший президент Стэнфордского университета (с 2010 по 2016 год), американский учёный-компьютерщик, академик, бизнесмен, член правления Alphabet Inc (ex Google), Cisco Systems, Atheros Communications и Фонда Гордона и Бетти Мур. Марк Андриссен назвал его «крёстным отцом Кремниевой долины».

Хеннеси получил бакалаврскую степень в Университете Вилланова (Филадельфия), а затем докторскую степень Университета Стоуни-Брук в Нью-Йорке. С 1977 года он преподавал в Стэнфордском университете, впоследствии там же руководил лабораторией компьютерных систем, затем стал заведующим кафедрой компьютерных наук, деканом инженерного факультета, проректором (вместо Кондолизы Райс) и, наконец, президентом Стэнфорда.
Совместно с группой исследователей из Стэнфорда создал MIPS Computer Systems Inc — фаблесс-компанию, проектирующую микроэлектронные устройства.

Также Хеннеси является членом Ассоциации вычислительной техники (ACM) и научным сотрудником Музея компьютерной истории, обладателем почетной медали IEEE и степени почетного доктора математики в Университете Ватерлоо (Канада) и, как уже было сказано выше, лауреатом премии Тьюринга.

Совместная книга Паттерсона и Хеннеси «Архитектура компьютера и проектирование компьютерных систем» за 26 лет с момента выхода неоднократно переиздавалась и дорабатывалась с целью отразить актуальные изменения в области аппаратного обеспечения. Книга отлично иллюстрирует взаимодействие между аппаратными средствами и системным программным обеспечением, при этом особое внимание уделяется многоядерным вычислительным системам и параллельному программированию.

Мнение amartology:

«Эта книга — фундаментальный труд по цифровой электронике от отцов-основателей современного процессоростроения. Она выдержала пять изданий и была серьёзно доработана за это время, только приобретая актуальность.

Это очень серьёзный и глубокий разбор принципов построения современного цифрового «железа» и его взаимодействия с софтом.

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

В пару к этой книге могу еще порекомендовать «Цифровую схемотехнику и архитектуру компьютера» Харриса и Харрис — более новую и прекрасно дополняющую основами рассчитанный на продвинутую аудиторию труд Паттерсона – Хеннесси. Обе книги достаточно хорошо переведены на русский язык и вряд ли перестанут быть актуальными в обозримом будущем».

VI. «Электроника — практический курс», Мартин Хартли Джонс (1995)

image

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

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

О книге и её создателях:

Мартин Хартли Джонс получил докторскую степень в области электроакустики в Манчестерском университете, где на какое-то время остался в качестве преподавателя. В 1976 году он присоединился к ведущей профессиональной аудиокомпании Neve Electronics в Кембридже в качестве технического директора и возглавил разработку таких инноваций, как первая в мире цифровая диспетчерская для BBC и первая в мире система управления вещанием. Позже, в 1985 году, он присоединился к Smiths Industries plc в качестве технического директора морского подразделения (Kelvin Hughes Ltd), где он разработал цифровые радиолокационные системы с компьютерным управлением для гражданского и военного применения. Сменив несколько управляющих должностей в этой компании, он в 2002 году решил открыть свой собственный консалтинговый бизнес в Кембридже, является аккредитованным бизнес-консультантом IBD. При всём этом он не забывал и о науке и продолжает оставаться научным сотрудником таких международных научных обществ, как IMarEST (Институт морской инженерии, науки и технологий), IOP (Институт физики), IOA (Акустический институт) и AES (Общество аудиоинженерии).

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

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

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

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

Мнение amartology:

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

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

Но в целом, повторюсь, ничего необычного, — так что лучше купите Хоровитца – Хилла».

Какие еще IT-книги, которым больше 20 лет, вы могли бы включить в эту подборку? Делитесь нестареющей классикой в комментариях. Ну а если у вас есть свои достойные тексты, заявляйтесь на конкурс IT-статей «ТехноТекст-2020»: Хабр поможет и им стать нетленкой.

ссылка на оригинал статьи https://habr.com/ru/company/habr/blog/521172/

Что нового в сфере квантовых коммуникаций — система распределения ключа для десяти участников сети

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


Фото — Shahadat Rahman — Unsplash

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

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

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

Как это работает

Для этого проекта инженеры предложили отойти от классических подходов кодирования в системах квантового распределения ключа и передали криптографическую информацию с помощью орбитального углового момента (orbital angular momentum, OAM) — он описывает направление вращения и силу закрученности фотона и обладает высокой информационной вместимостью. Ученые даже сравнили поляризацию фотона в традиционных системах квантового распределения ключа с подбрасываем монеты, а OAM — с игральной костью, обладающей бесконечным числом сторон.


Фото — jesse ramirez — Unsplash

Для обмена данными была предложена схема под названием «передача посылки» (pass-the-parcel). Фотон с закодированной информацией по очереди принимает десять участников сети, каждый из которых производит определенные операции с OAM без считывания. Таким образом, фотон не разрушается и возвращается к отправителю. Последний производит контрольное считывание и сравнивает состояние фотона до и после передачи. Что самое главное — новых подход позволяет распределять ключ, даже если друг другу доверяет лишь часть участников сети — например, три или четыре. Классические системы пока не могут похвастаться такими возможностями.

Что с этого ИТ-индустрии

Подобные разработки приближают появление коммерческих и государственных квантовых сетей (подобные проекты уже обсуждают в Министерстве энергетики США), удешевляя стоимость инфраструктуры и повышая ее теоретическую эффективность. Так, в австрийском Институте квантовой оптики и квантовой информации убеждены, что в ближайшие пять лет квантовые сети смогут объединить вычислительные устройства на расстоянии в 50–100 километров.

О чем мы пишем в корпоративном блоге 1cloud.ru:

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

ссылка на оригинал статьи https://habr.com/ru/company/1cloud/blog/520896/

Почему разработчикам так много платят: опыт  Netflix, Wistia и Stripe

Опубликовано автором
Ответить

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

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

Причина #1: В 10 раз лучше, чем «нормально»

Еще в 1960-х годах было проведено знаменитое исследование, в рамках которого девять разработчиков разной квалификации должн были за отведенное время решить ряд задач от написания кода до поиска багов. Исследователи предполагали, что лучший из разработчиков в среднем справится с заданием в 2-3 раза лучше. Однако оказалось, что наиболее умелый программист оказался гораздо лучше самого слабого – он в 25 раз быстрее находил баги, на 20 минут быстрее справился с задачей по написанию кода, а его код работал в 10 раз эффективнее.

Генеральный директор Netflix Рид Гастингс в колонке на сайте CNBC упомянул это исследование и прокомментировал его:

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

[..]

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

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

Причина #2: Талантливые инженеры помогают менеджерам

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

Рид Гастингс
Рид Гастингс

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

Причина #3: Компания больше работает над публичным образом

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

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

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

Причина #4: Сильные инженеры улучшают рекрутинг

Необходимость нанимать сильных инженеров заставляет компании более вдумчиво подходить к рекрутингу. CTO Stripe Грег Брокман рассказывал, что компания применяет для решения этой задачи принципы маркетинга – замеряет метрики для определения эффективности каналов привлечения кандидатов, проводит эксперименты и постоянно оценивает их.

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

Заключение

Несмотря на то, что выводы любимого Ридом Гастингсом исследования про 10x разработчиков разделяют не все (достаточно почитать этот тред на Hacker News), очевидно, что инженеры помогают компаниям становиться лучше. И делают они это не только с помощью написания кода и поисков багов, поэтому и их зарплаты скорее всего продолжат расти.

ссылка на оригинал статьи https://habr.com/ru/post/521448/

За что критикуют инициативы британских интернет-регуляторов — разберемся, что к чему

Опубликовано автором
Ответить
Более года назад британские власти выдвинули новые предложения по совершенствованию интернет-регулирования, но вокруг опубликованного ими «Online Harms White Paper» разгорелось масштабное обсуждение. «Белую бумагу» раскритиковали, и пока документ окончательно не перешел в формат законопроекта, эксперты формулируют критику и высказывают опасения.


/ Unsplash license / Jon Tyson

Что еще за вайтпейпер

В 2019 году была опубликована первая версия инициатив по усилению контроля за деятельностью интернет-компаний и распространяемого в сети контента. За некоторое время «Online Harms White Paper» претерпел точечные модификации: сейчас для ознакомления доступна его полная версия (подразделы начинаются с компактных саммари, выделенных серыми блоками) и обобщенный вариант (для погружения в тему, если вы впервые сталкиваетесь с такой документацией).

Дополнительное чтение у нас на Хабре:

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

Альтернативные мнения и критика

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

Свой анализ инициативы и альтернативные предложения в сентябре этого года представили специалисты Free Speech Union (FSU) — местной организации, оказывающей юридическую поддержку по вопросам посягательств на свободу слова. В тексте пресс-релиза они поставили «Online Harms White Paper» в один ряд с широко критикуемым немецким законодательством по борьбе с «fake news» и китайским регулированием «слухов», представляющих угрозу общественной безопасности.


/ Unsplash license / Markus Spiske

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

Свои доводы эксперты обосновали отсылками к уже действующим нормам и заявили, что «Online Harms White Paper» ставит под угрозу и вполне законные практики — например, возможность открытой политической дискуссии. Плюс — не дает инструментов для апелляции, если пользователь того или иного ресурса не согласен с удалением контента по требованию самой площадки.

Что дальше

В контексте сложной эпидемиологической ситуации и всевозможных скандалов вокруг этой темы в медиа и СМИ звучат прогнозы о том, что власти могут обратить еще более пристальное внимание на регулирование интернет-отрасли, соц.сетей и онлайн-контента. Дело в том, что в начале распространения эпидемии в стране стали активнее обсуждать «теории заговора», а некоторые — вроде Дэвида Айка — успели не только попасть под блокировки Facebook и YouTube, но и поучаствовали в публичных акциях против «локдауна». Но есть и мнение о том, что излишнее «закручивание гаек» может только поспособствовать популярности таких конспирологов.

Исходя из этих соображений и необходимости проверки инициативы на стороне профильных сообществ и комитетов вроде NSPCC (National Society for the Prevention of Cruelty to Children), формирование законопроекта отложили. Паузой все еще надеятся воспользоваться эксперты, которые хотели бы предложить альтернативные варианты регулирования интернет-пространства страны.

Что еще почитать в нашем корпоративном блоге:

ссылка на оригинал статьи https://habr.com/ru/company/vasexperts/blog/521354/