[Из песочницы] Инструмент анализа скорости PHP-функций

Ускорение печати из терминальной сессии Windows Server или доработка EasyPrint напильником

Светомузыка из BMW

На Telegram обнаружена очередная успешная атака

Функциональная безопасность – старшая сестра информационной безопасности

Безопасности на хабре посвящен целый хаб, и, пожалуй, никто особенно не задумывается, что именно вкладывается в понятие «безопасность», и так все ясно: информационная безопасность (security). Однако, есть еще и другая сторона безопасности, safety, связанная с рисками для здоровья и жизни людей, а также окружающей среды. Поскольку информационные технологии сами по себе опасности не представляют, то обычно говорят о функциональной составляющей, то есть о безопасности, связанной с правильным функционированием компьютерной системы. Если информационная безопасность стала критична с появлением интернета, то функциональная безопасность рассматривалась и до появления цифрового управления, ведь аварии происходили всегда. Информационной безопасности АСУ ТП посвящено немало статей на хабре. Функциональной безопасности авторы тоже касались, как в хабе по SCADA, так и в хабе по промышленному программированию АСУ ТП, но, как мне показалось, несколько вскользь. Поэтому я предлагаю короткую информацию об этом важном свойстве, от которого напрямую зависит, получит ли SkyNET контроль над человечеством.
В статье сделаны некоторые обобщения для АСУ ТП, а также для встроенных и кибер-физических систем.

Заслуживает ли внимания функциональная безопасность?
Важна ли функциональная безопасность на сегодняшний день? Ведь фокус внимания в основном направлен на информационную безопасность.
С одной стороны, функциональная безопасность напрямую связана с надежностью аппаратной составляющей, и здесь осталось немного нерешенных задач, электроника безотказно работает годами, а если и этого недостаточно, то всегда есть возможность резервирования. Но ведь есть еще программная составляющая, на которую как раз и возлагается управление функциями безопасности. Недавно на хабре была опубликована статья «Самые дорогие и судьбоносные ошибки в ИТ-индустрии». В ней дается описание нескольких кейсов, когда ошибка в софте систем управления космическими системами обходилась в миллионы долларов, и это далеко не все известные случаи. А еще есть системные проекты, включающие механическую, электронную и электрическую составляющие, и здесь, к сожалению, тоже есть место для ошибок.
В статье «Интернет вещей (IoT) – вызовы новой реальности» проведен анализ киберугроз и методов обеспечения информационной безопасности для интернета вещей (Internet of Things, IoT). Одним из потенциальных рисков является перехват управления на уровне физических устройств. Тогда злоумышленник может заставить систему управления выполнять опасные функции. В этом случае информационная и функциональная безопасность являются двумя сторонами одного и того же явления. Свойство информационной безопасности должно обеспечить доступность, целостность и конфиденциальность данных системы управления. Свойство функциональной безопасности должно обеспечить корректное выполнение функций системы управления, а при возникновении отказов перевести объект управления в так называемое безопасное состояние.
Еще одним мотивом знакомства с функциональной безопасностью является понимание процесса сертификации и лицензирования. Объекты, которыми управляют компьютерные системы, зачастую создают риски для окружающей среды и людей (химическое производство, газовая и нефтяная промышленность, медицинские устройства, атомные и другие электростанции, железнодорожный, автомобильный, авиационный транспорт и т.д.). Компьютерные системы управления такими объектами должны выполнять функции безопасности и обладать определенными характеристиками (резервирование, отказоустойчивость, самодиагностика, устойчивость к внешним экстремальным воздействиям и т.п.). Контроль за разработкой, внедрением и эксплуатацией компьютерных систем управления, важных для безопасности, осуществляется государственными органами сертификации и лицензирования. Таким образом, разработчикам систем приходится знакомиться с требованиями к функциональной безопасности.

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

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

Подобная архитектура реализуется для встроенных систем (Embedded Systems), широко применяемых в промышленной автоматизации, бытовых устройствах, автомобильных системах, медицинских устройствах, коммуникационных сетях, роботах, дронах и т.п.
В АСУ ТП (Industrial Control Systems) применяется более разветвленная архитектура, включающая объединенные в сеть датчики, программируемые логические контроллеры (ПЛК), исполнительные механизмы, хранилища данных, сервера и рабочие станции.

Schneider Electric – Modicon Quantum PLC

Наиболее сложной является типовая архитектура IoT, я вкратце о ней рассказал в статье на хабре.

Управляющая система реализуется на уровне Device Layer. Ее программно-аппаратная реализация может быть аналогична встроенной системе. С точки зрения информационной безопасности критическими являются интерфейсы DL-NL & DL-AL доступа к уровню Device Layer.
Таким образом, к системам управления, для которых важно рассматривать свойство функциональной безопасности, относятся АСУ ТП, встроенные системы и IoT.

Стандарты, относящиеся к функциональной безопасности
В области стандартизации существует такое понятие, как “umbrella standard”, т.е. основополагающий «вертикальный» стандарт верхнего уровня. Для функциональной безопасности таковым является МЭК 61508 «Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью» (IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems), включающий семь частей. Данный стандарт переведен на русский язык и внедрен в Российской Федерации в виде ГОСТа.
Дальше я постарался кратко интерпретировать основные положения МЭК 61508. Они, скажем так, неидеальны, однако, здравый смысл в них имеется. Ниже следует авторская обработка с учетом личного опыта в сфере функциональной безопасности.
Согласно положениям МЭК 61508, под функциональной безопасностью (functional safety) подразумевается корректное функционирование, как системы управления, так и управляемого ею оборудования. Таким образом, для обеспечения функциональной безопасности необходимо сначала определить функции безопасности (safety functions), необходимые для снижения риска управляемого оборудования, а также для достижения и сохранения этим оборудованием безопасного состояния (например, функции противоаварийной защиты). Далее, система управления должна обладать свойством так называемой полноты безопасности (safety integrity), под которым МЭК 61508 подразумевает вероятность того, что система будет корректно выполнять функции безопасности при всех заданных условиях в течение заданного интервала времени.
При обеспечении полноты безопасности (safety integrity) учитываются два типа отказов: случайные (random failures) и систематические (systematic failures).
Случайные отказы вызваны выходом из строя аппаратных компонентов и парируются такими методами, как резервирование, самодиагностика, физическое и электрическое разделение компонентов, повышение устойчивости к внешним воздействиям и т.п.
Систематические отказы вызваны ошибками проектирования, в том числе, и ошибками программного обеспечения. Устранение систематических отказов возможно путем совершенствования процессов проектирования и разработки, тестирования, управления конфигурацией, проектного менеджмента и т.п. Кроме того, поскольку классическое резервирование не позволяет избежать систематических отказов, применяется так называемое диверсное (diversity) резервирование, когда резервные каналы разработаны с применением различного программного и аппаратного обеспечения. Дорого, неудобно, но иногда помогает.
Положения МЭК 61508 детализированы для потенциально опасных областей. Существуют, например, следующие стандарты:
IEC 61511, Functional safety – Safety instrumented systems for the process industry sector;
IEC 62061, Safety of machinery – Functional safety of electrical, electronic and programmable electronic control systems;
IEC 61513, Nuclear power plants – Instrumentation and control for systems important to safety;
ISO 26262, Road vehicles – Functional safety;
EN 50129, Railway Industry Specific – System Safety in Electronic Systems;
IEC 62304, Medical Device Software;
В аэрокосмической отрасли на МЭК 61508 не ссылаются, тем не менее, подход похожий:
для авионики разработан стандарт RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification;
в космической отрасли стандарты разрабатываются космическими агентствами, например NASA использует стандарт STD 8719.13, Software Safety Standard.

Выводы
В дружной, но непредсказуемой семье «безопасность», борющейся за свободу информационных технологий от неприемлемых рисков, живут себе две сестры: старшая, функциональная безопасность (safety), и младшая, информационная безопасность (security).
Для управляющих систем, к которым относятся такие архитектуры, как АСУ ТП, встроенные системы и интернет вещей (Device Layer), основополагающим свойством является функциональная безопасность.
Под функциональной безопасностью подразумевается корректное функционирование, как системы управления, так и управляемого ею оборудования.
Информационная безопасность в таких системах носит дополнительный характер и должна предотвращать доступ злоумышленников к контролю над системой управления и управляемым оборудованием.
Для объяснения основных аспектов функциональной безопасности планируется следующий цикл статей:
Теория надежности и функциональная безопасность: основные термины и показатели;
Методы обеспечения функциональной безопасности систем управления;
Жизненный цикл безопасности для системы управления;
Тестирование систем управления, важных для безопасности.
Тематика может корректироваться в зависимости от полученных комментариев.

Let's block ads! (Why?)

Opera призывает своих пользователей сменить пароли

Всему своё время

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

Эта статья — расшифровка доклада Романа Ивлиева (CIO Banki.ru) на обучающей конференции HighLoad++ Junior, которая прошла пару месяцев назад в Москве в рамках фестиваля “Российские интернет-технологии”.

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

Посмотрим примеры и поищем ответы на вопросы:

1. Настолько ли ваш highload — highload?
2. Считать ли хабрэффект поводом для внедрения высоких технологий?
3. «Костыль» или «высокотехнологичное решение» — что выбрать? Плюсы и минусы.
4. Как выбрать момент для начала новой эры? Есть ли критерии, когда имеет смысл начинать оптимизировать ваше приложение и внедрять крутые штуки «по-взрослому».
5. Как можно использовать «список Бунина» для достижения очень неплохих показателей, и все ли пункты реально нужны вам?
6. Как работать с техническим долгом, чтобы он не зарастал мхом?

В заключение Роман Ивлиев расскажет про несколько примеров из жизни banki.ru в части замены технологических решений в области высоких нагрузок, и что из этого вышло.

Всему свое время

Роман Ивлиев (Банки.ру)

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

А это про Банки.ру:

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

Я объясню, откуда взялись такие цифры и, вообще, зачем они здесь. Никакой рекламы, это то, что у нас на самом деле есть. Трафик ни к чему, но тем не менее, мы в сутки обслуживаем примерно полмиллиона человек, т.е. это не число запросов, это число уникальных людей, число запросов, естественно, больше — оно там к двум миллионам, может быть, даже к трем, а когда бывают «чудеса» с валютой или отзывают лицензию у какого-нибудь клевого банка, у нас бывают и цифры, которые зашкаливают. В 2014-ом году, когда Центробанк отпустил доллар, нагрузка на сервис курса валют выросла в один день в 85 раз, т.е. вчера у нас было 10 запросов, а потом было 850 запросов. В секунду, естественно.

О чем я хотел рассказать?

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

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

Все-таки HighLoad или не HighLoad? Т.е. так ли ваш проект нагружен, и является ли он, вообще, нагруженным?

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

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

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

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

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

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

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

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

Тем не менее, является ли это поводом для того, чтобы принимать решение, что вы наконец-то стали HighLoad? На самом деле — ни фига. Потому что хабраэффект у вас через 20 минут закончится, отлегло. И в это «отлегло» вы свято можете верить дальше, потому что, скорее всего, так и произойдет. Я это знаю, потому что в 2014-ом году нас колбасило три дня — три дня люди интересовались курсами валют, т.к. доллар был 30-40 руб., потом стал 90, а в какой-то момент больше 100. Вот нас три дня поколбасило, потом отпустило. Было ли это для нас признаком того, что что-то произошло? Да, было.

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

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

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

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

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

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

«Костыли» — это не способ передвижения, это способ заставить ваше решение работать.

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

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

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

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

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

Чаще всего это будет сделано хорошо, здорово, аккуратно, но в ситуации, когда вас накрыло, вы ничего с этим сделать не сможете, у вас просто нет на это времени. Бывает такая ситуация, как у нас, например. В свое время, когда тоже приплохело, вкрутили Varnish по-быстренькому на продакшн и, в принципе, там его потом и оставили, только донастроили, потому что в моменте, когда прикрутили просто так, он работал не очень хорошо. В частности, он кэшировать начинал города, из которых идут люди, баннеры, которые люди видят, какие-то личные сообщения, а в конечном итоге он закэшировал 404-ую ошибку чью-то и всем дружно раздавал 404-ую ошибку, минут 5, наверное. Но быстро, опять же, поняли, что что-то здесь не то. Потом мы все это довели до ума, доконфигурировали и т.д.

Кстати, вот он, один из алгоритмов. Очень важный пункт третий — он часто распространенный, особенно в небольших компаниях, когда есть такой шеф driven development, когда прибегает шеф, и говорит: «Мне тут сказали, что вот так вот надо сделать». Первое, что приходит в голову: «Но это шеф, елки-палки, нельзя же обидеть человека». Вот тогда рождаются «костыли», даже не технологически, а просто лишь бы он пропал с глаз, а потом уже как-то вечерком доделаем.

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

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

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

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

Вот, по поводу «заранее».

К вопросу о прогнозировании. Чисто теоретически это можно было, если бы так был устроен мир, и не было бы проблем, вообще. Т.е. если у вас 10% CPU (CPU здесь для примера), которые генерирует 10 пользователей, 20% — 20, 30% — 30 и т.д. до 1000 условно, если у вас 10-ти ядерник. На самом деле так почти никогда не бывает. Т.е., наверное, бывает, но я не встречал. Чаще бывает, когда у вас 100 пользователей — это 10% CPU, а 200 пользователей — это уже, увы, пипец, приплыли. Бывает так, что и 200 пользователей — это ничего, но при этом вы садитесь в другом месте. Поэтому есть, условно говоря, 4-5 точек в вашей системе, которые нужно мониторить всегда.

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

Бывает ошибка конфигурации. Самая распространенная причина того, что что-то идет не так — это ошибка конфигурации. Т.е. берут, например, postgress из коробки, ставят его, он работает. На тестовой машине работает, на 5-ти пользователях работает, на 10-ти работает, на 20-ти — не работает. Такая же петрушка происходит практически со всем, т.е. если вы запрограммировали свое решение, и оно у вас шикарно работает, вообще не обязательно, что оно будет работать дальше. Поэтому единственный способ здесь что-то сделать — это проводить периодические исследования, проводить периодические срезы этих вот пороговых значений, грубо говоря, поймать момент, когда ваша подаваемая нагрузка начинает изменять какую-нибудь кривую. У вас есть, например, нагрузка на CPU, она почти линейная. Вы начинаете подавать, она начинает чуть отклоняться, в какой-то момент она отклонится вот так вот, или не отклонится, но при этом отклонится в другом месте… Поэтому, если взять какой-нибудь Zabbix, то можно на один экран вывести пять мониторчиков, на котором видно каждый с каждым. Лучше выводить их в столбик. Почему в столбик? Потому что у вас четко будет видно, что происходит со всеми параметрами при росте нагрузки.

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

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

Можно поискать какие-нибудь закономерности в поведении? Конечно, можно. Но каждая закономерность — она очень условная. Либо вам нужно реально в это врубаться конкретно, тратить уйму времени, понимать, как ведет себя ваше железо. Потом вы внезапно поймете, что железо у вас уже другое… Hetzner — слышали про такого провайдера немецкого? А слышали, из чего сделаны его дата-центры? Из десктопов всяких и б/у серверов, короче, из кучи всякой непонятной фигни. И в какой момент времени ваше решение работает на каком железе, вы не узнаете никогда, потому что иногда складывается впечатление, что даже они не знают, где в какой момент у них что работает. Тем не менее, когда вы увидите, что у вас что-то шатануло, лучше все-таки протыкать это дальше, поисследовать, потому что реально, даже на наших нагрузках, когда у нас 400-500 запросов в секунду приходит в приложение, мы можем себе позволить, не сильно напрягаясь, дать туда 1000. 1000 — это в два раза. В два раза — это, в принципе, достаточно приличный запас для того, чтобы понять, что реально произошло.

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

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

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

Но есть такая любовь у человечества — к среднему. Все любят среднее. Т.е. все говорят: «Сколько у тебя пользователей?» — «Ну, в среднем, 500-600». Обычно так примерно звучит. Как это выглядит на самом деле? А вот так, как на графике выше (суточный профиль нагрузки). Т.е. в среднем у вас 4 тыс. с копейками. Т.е. можно сказать, что «наша система в среднем принимает 4.5 тыс. человек в час», условно. Но при этом 10 тыс., которые произойдут у вас, они на самом деле произойдут, поэтому когда применяются всякие системы мониторинга, сбора анализов и т.д., нужно очень аккуратно подходить к вопросу выбора этой самой метрики, про которую вы собираетесь мерить. Среднее — это очень паленая метрика, честно вам скажу. Она реально подходит для, по опыту, ловли трендов. Т.е. по среднему можно ловить тренд. Т.е. если среднее начинает отклоняться в какую-то сторону, вверх-вниз, тогда у вас сто пудов внутри где-то что-то изменилось. Это повод для того, чтобы полезть внутрь, более изучать детально, возвращаться к полноценному графику и т.д.

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

Соответственно, если мы берем страницу, которая отвечает за 50 мс, и страницу, которая отвечает за 2 с, то в среднем они отвечают за 1 с. Опять же, потому что там ± погрешность, т.е. медленно. А на самом деле медленно отвечает только одна из них, вторая отвечает очень быстро, и в принципе трогать ее и не нужно. Потому что существует известный программистский паттерн, как в анекдоте про солнышко, что если ты видел, что солнце взошло на востоке, а зашло на западе, не трогай его, пусть оно так дальше и работает.

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

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

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

Я не встречал еще людей, которые не впихивают какие-то «костыли» в свои решения. Даже крутые парни из Badoo или Yandex про это рассказывают на конференциях (можно посмотреть записи предыдущих HighLoad), они честно признаются: «Да, это «костыль». И что? Я тоже говорю: «Да, это «костыль». У меня есть Битрикс, который тоже не очень хорошо работает, я умею его делать быстро работающим путем впихивания ему не совсем правильных решений. «Костыли» — это некое решение, которое спасает в данной ситуации, но потом им нужно заниматься дальше.

По поводу того, что я говорил, что у вас не все сразу сломается. Обязательно где-то что-то отвалится в первую очередь, где-то что-то отвалится во вторую очередь… Поэтому есть такая штука — я ее обозвал «компонентная оптимизация».

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

Предположим, вы нашли узкие места. Надо понять, возможно ли, вообще, все это улучшить? Потому что, в принципе, как я уже сказал, у любой системы есть ограничения по своим возможностям. Если ваша СУБД не может делать 100 тыс. селектов одновременно, то она и не сможет, чего вы с ней ни делайте. Скорее всего, пришло время выбирать какое-то другое решение — например, тот же самый популярный сейчас в разговорах Tarantool. Он не решит все ваши вопросы NoSQL, он не решит вопросы даже Postgress (подставьте любое другое слово), он решит какие-то другие ваши вопросы, которые вам нужно решать в этот момент.

Деньги и время. Вряд ли кто-то из вас работает в государственных компаниях. Но спрошу — есть? В аудитории таких два человека. Это те компании, в которых вопрос денег стоит остро, но не так остро, как в других компаниях. Я сам работал в государственном предприятии. Я знаю, какие там объемы, и я знаю, как у них отбирают бюджеты и отдают их назад, но, тем не менее, это не так критично, как, например, у нас. Мы не можем себе позволить взять 30 инженеров и заставить их заниматься оптимизацией. Они, конечно, заоптимизируют, и все это будет работать адски быстро, ловко и классно, но время, которое мы потратим на это, по сути, неполученная прибыль — это убыток. За это время, мы не сделаем чего-то нового, клевого, и компания будет не рада.

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

Что делает Landing Page? Вы берете статическую html, на которой ваш дизайнер рисует красивую картинку, и вы всех Nginx’ом на нее приземляете. Nginx раздает эту картинку со скоростью 80 тыс. запросов в секунду, не обламываясь даже с самого маленького современного сотового телефона — он сможет раздать с такой производительностью. И 80 тыс. человек в секунду смотрят вашу картинку. При этом ваш портал знать не знает, что к вам кто-то пришел, потому что до него еще не дошли. А дальше — традиционная маркетинговая воронка продаж — с каждым следующим шагом, с каждым следующим скролом количество людей, которое доехало до низа, где кнопка «войти» или «купить», или еще чего-то, оно уменьшается. «Костыль»? «Костыль». Решение? Почему нет? Вы, по сути, ничего не делая, используя ту же самую инфраструктуру, взяли и спасли себя от смерти. Потому что, если к вам придет 80 тыс. запросов в секунду в приложение, оно вообще не обрадуется, я вас уверяю.

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

Список Бунина, Олега Бунина — вы, наверное, слышали про этого персонажа? У него есть список, список выглядит вот так:

Это не все, там еще 100500 пунктов, это паттерные разработки высоконагруженных систем. Чтобы вам было проще, то вот так на самом делеJ:

Рекомендую поискать в YouTube «Олег Бунин разработка высоконагруженных систем», там он про это все рассказывает, про каждый пункт, их у него в рассказе штук 20. На самом деле их не 20, но, тем не менее, чаще всего, это как на картинке вышеJ

Т.е. человек, который впервые на это смотрит, говорит, е-мое. Объясню, почему «е-мое».

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

На самом деле, если не быть таким категоричным, я почему сказал про проекты? В проекте, скорее всего, вам не нужно это все. Когда у инженера, который всегда делает то, что ему интересно, сайт начинает тормозить, он берет списочек и начинает проверять: «Ага, так, шардирование. Пойду почитаю». Почитал, посмотрел. «Давай я своих пользователей поделю по букве А и Ё». Не важно, что у него при этом всего 700 тыс. пользователей, одноядерный, слабенький сервачок с любой базой данных, и он может сделать селект по ID и вернуть ему данные по этому пользователю… Он начинает их шардировать, делать с ними всякие шутки — реплицировать, бэкапить, делать резервные шины. Ну, короче, развлекается, как хочет. У меня для этих целей выделен специальный человек, у которого работа «развлекаться, как хочет» — он просто целыми днями развлекается, ищет узкие, слабые места и т.д.

В этом списке (я почему вас к нему отправляю?) есть часть вещей, которые можно сделать, вообще не имея никакой квалификации. Т.е. быстренько прогуглить — «в Nginx как раздать статику?», «как ее зипануть?», «как увеличить размер буфера при сортировке в Postgress?» или, например, «как какой-нибудь slow log настроить в MySQL?». Вы найдете очень быстро. Это, вообще, не нужно быть даже DBA. Вы просто пришли со своей маленькой задачей «у меня тупит запрос». И вам Google быстро рассказал, почему он тупит. Сначала Google расскажет, что вы тупите, а не ваш запрос, потому что он всегда так делает.

Откуда, вообще, берутся все проблемы? Потому что нет стандарта разработки. Не ищите его. Его нет. Нет стандарта, который говорит: «Разработка
высоконагруженных систем. Версия 1 от 2016 года, Сколково». Я думаю, мы когда-нибудь до этого доживем, но тогда я уйду из индустрии, честно. Когда появятся такие документы. Парни инновационные — они сейчас могут, в принципе.

Не все нужно здесь и сейчас — то, про что я говорил.

Вот шардирование — классная штука, она очень круто работает и, например, Badoo’шники без нее давно бы сдохли, или, например, Яндекс бы тоже без него сдох. И вообще, все крупные порталы используют из списка Бунина все пункты, которые там есть, и еще кучу пунктов, которых там нет. Потому что там есть всякие ноу-хау и т.д.

Тот самый «костыль». Простое решение — самое эффективное. Т.е. вставка какой-то примитивной конструкции в код. Для примера можно взять какой-нибудь форум, неважно на какой платформе. Чаще всего внизу у него есть список активных пользователей — кто в данный момент смотрит этот пост. Этот списочек в классической версии форума любого движка каждому пользователю генерируется. Т.е. вы пришли на страничку, вам этот select * from (какая-то табличка) — бац, появилась эта вот штука. Естественно, когда у вас приходит 200 тыс. пользователей, то база делает эту операцию 200 тыс. раз. Так ли важно, что через секунду или через 2 секунды, даже если кто-то появится в этом списке, от того, что он там появился, вам по большому счету, ни тепло ни холодно, поэтому такие конструкции можно, например, складывать в кэш, или например, складывать в отдельные структуры и прогревать их, например, кроном.

Почему я вспоминаю Badoo’шников? Реально крутые чуваки. Они очень много сил вкладывают в развитие, но это, знаете, такой Тема Лебедев от веб-разработки. Т.е. это долго, дорого и еще одно слово. Т.е. за дорого не возьмусь, за долго — скорее всего, нет, но последнее слово — 100 пудов про них, потому что все их решения чаще всего потом обретают некую индустриальную обертку, чем они кладут большую свинью половине человечества, потому что люди берут эти решения и начинают их использовать.

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

Это классно, интересно. Мы всегда с удовольствием следим. Особенно эта штука в последнее время, я могу ошибаться, но мне кажется, что это про javascript фреймворки. Мне кажется, что они рождаются со скоростью один фреймворк в час, по последним моим наблюдениям. И умирают с такой же скоростью. Т.е. вроде бы был, а потом бац — и нет.

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

Помните, история была, когда один из джаваскриптологов крутых взял и отозвал из NPM свой кусочек кода. И что произошло? Произошел ахтунг. Все такие «Е-мое! Развалилось». Если бы чуваки это предусмотрели заранее, как мы это сделали… Минутка саморекламыJ — мы себе поставили кэширующие сервера, и у нас все пакетики перед тем, как попасть на продакшн, сначала оседают на нашем кэширующем серваке. Решений для этого — вагон. И пакеты операционной системы, и javascritp фреймворки… В общем, все, что мы тащим с улицы, мы тащим на самом деле не с улицы, а с некоей промежуточной коробки, которая все это хранит. И даже, если на улице кто-то что-то убил или, например, изменил url… Классная фишка — изменить url у пакета, а у вас он, например, захардкожен где-нибудь в вашем замечательном композере. У вас захардкожен url, и «ой-ой-ой, не собралось», а у вас это на продакшне работает, и там «ой», и у вас такая картинка классная, вы все ее видели, когда стили не загружаются, например. Чаще всего, это классно. Мы этот вопрос решили вот так. Т.е. мы не стали заморачиваться, новый-не новый, старый-не старый, у нас есть место, которое всегда хранит те версии, которые мы используем, и даже если весь интернет умрет, то у меня с локалочки все это дело подтянется, и все будет работать.

Это актуально стало. Мы начали этим заниматься, потому что РосКомНадзор заблокировал GitHub, зараза такая. И он это делал с завидной регулярностью. В итоге мы оставались без наших замечательных пакетов. В итоге нашли решение, поставили коробочку маленькую, она это все сохраняет.

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

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

Про «костыли», тех. долг и прочее. Еще и по поводу этого хайпа. Это я не к тому, что вообще не надо ничего трогать, это я к тому, что если вы что-то решили потрогать, то, как в старой доброй русской поговорке, помните, что как только вы потрогали, у вас остаются последствия, и с этими последствиями вам придется жить. Так вот, про последствия «костылей». Есть такая штука –технический долг. Все про него слышали. Это когда вы знаете, что у вас что-то не работает, но при этом вы это не чините. Потому что либо это вам не сильно мешает, либо это вам мешает, но не очень… Это штука, которая есть. Кто-то его записывает, кто-то его не записывает. У кого-то есть списочек задач, которые надо сделать потом? Есть. Вот, это технический долг, практически.

Как с ним работать? Расскажу, как с ним работаем мы.

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

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

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

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

Долг копится всегда, я не видел ни разу, ни одной компании… Я про одну читал, которая утверждает, что они умеют работать без дефектов, т.е. у них появление дефекта — это «красная тряпка», которая говорит: «все бросили, пошли чинить дефект». Я, честно, не знаю, с какой скоростью они двигаются вперед. Я не доисследовал этот вопрос, тем не менее, мне кажется, что это не очень хорошо работает.

И в заключение. Важна стратегия! Почему стратегия? Люди, которые работают с вами, все должны думать одинаково. Т.е. в ситуации, когда случается какой-то факап, все должны действовать примерно одинаково. Поэтому человечество придумало общение — чтобы можно было поговорить со своими коллегами. Я понимаю, что программисты не очень любят говорить со своими коллегами, но тем не менее. Неплохо бы собраться и хотя бы найти крайнего, т.е. сказать: «Если случается какая-нибудь беда, вот ты будешь исправлять все это». Скорее всего, так не произойдет. Т.е. естественно, чинить будут помогать все, но я видел, как это происходит вживую. Обычно выглядит так: половина команды, говорит: «Ну, е-мое!», и типа думает, что делать. Вторая половина команды говорит: «Ну, это все,
короче, блин… Было 100 запросов в секунду, а теперь 500! Ладно, короче». Потом находится кто-то один, называет мальчиков девочками, девочек — мальчиками, чтобы взбодрить внутреннее эго и т.д. и говорит: «Ну, давайте немножечко подумаем».

Подумаем. Это важно! Вообще, программистам свойственно думать. Об этом думать нужно тоже — о том, что случись чего, что делать. У нас есть некий план такой короткий, на 5 пунктов, что делать, если случилась беда.

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

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

Риски оценивать надо всегда. Что такое оценивание рисков? У нас это выглядит примерно так: сколько я потеряю денег, если я проваляюсь минуту. Ну, $100, условно говоря. А на сколько мне за это потом прилетит? Или на сколько компании от этого будет плохо?

Еще есть классная вещь, про которую стоит говорить отдельно — это репутационные риски, т.е. каждый ваш факап — это не факап денежный, это факап репутационный. Т.е. если вы молодая начинающая социальная сеть facebook2, то лучше бы вам, конечно, не валяться, иначе шансов достичь facebook1, у вас не будет никаких. Это, кстати, показали ребята из китайского чатика, аналога WhatsApp’а, которые гордо вышли на рынок и им сказали: «Эй, ты кто, уходи отсюда». И они со своим миллиардом пользователей в Китае так и остались. Потому что что-то не предусмотрели, где-то что-то не подумали, не прикинули, и у них просто не было стратегии, что со всем этим делать.

Пробовать на кошках. Сейчас очень дешевый хостинг виртуальный — берете, делаете свою систему где-то в углу на коленке собираете, пихаете туда, что хотите, любые технологии, любые зоопарки. Пусть падает, пусть дохнет. Можете даже, смеху ради, туда отправить кусочек своего трафика. Nginx это умеет — помните про балансировку? Отправьте туда 10 человек, и посмотрите, что произойдет реально. Так делают ребята из Badoo. Это не реклама, просто они про это рассказывали.
Они свои сервисы анализируют на, по-моему, исландцах. Ну, типа, взяли самых сейсмостойких чуваков, которым по большому счету плевать, что в этом мире происходит, они сидят на своем острове и у них все хорошо, и этот Эйяфьякудль, у них все классно. Туда им грузят новые решения, потом смотрят. Они такие:
«Ах, пойдемте еще пивка попьем». Это реальная история, они про это рассказывали.

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

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

Более подробно о развитии highload-системы мы поговорим на вебинаре Романа Ивлиева “HighLoad-разработка с нуля и по шагам”. Это будет однодневный интенсивный мастер-класс, в рамках которого мы поговорим о развитии системы, рефакторинге и реинжиниринге гораздо более основательно:

Развитие системы

• Когда пора начинать что-то делать?
• Эволюция классического нагруженного веб-портала (на примере banki.ru)
• Методы оптимизации различных элементов системы
• Управляемая деградация и подготовка к ней
• Подготовка системы к росту: гибкость и надёжность
• Hype — его плюсы и минусы

Рефакторинг или реинжиниринг

• Непрерывность бизнеса при развитии системы
• Когда ещё можно безопасно использовать возмоножсти текущей системы?
• Когда нужно начинать строить заново?
• Цикл PDCA и “бережливое” развитие системы.

Let's block ads! (Why?)

На каких основаниях Alphabet претендует на членство в «клубе четырех запятых»

Alphabet возник чуть более года назад, в результате реструктуризации Google. Все акции Google были полностью конвертированы в акции Alphabet без каких-либо изменений их параметров. Холдинг Alphabet стал новым игроком на рынке, в состав которого на правах дочек вошли сама Google и все ее предыдущие проекты – в частности Calico, Fiber, Google Ventures, Google Capital, Google X, Life Sciences и Nest. Это, по мнению представителей компании, должно было обеспечить их большую самостоятельность и более четкую структуру руководства.

В ведении Google останется поисковая система, а также карты, рекламный бизнес, сервис Google Play Store, видеохостинг YouTube и разработка операционной системы Android, а также Chrome, Google Apps и социальная сеть Google+.

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

Генеральным директором Alphabet был назначен уже бывший руководитель Google — Ларри Пейдж. Сооснователь поискового гиганта Сергей Брин занял должность президента холдинга.

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

По словам Леви, пока представителям ИТ-сообщества так до сих пор и не ясно, как сейчас устроена работа Alphabet: «Похоже, что холдинг до сих пор переживает потрясение — и недавний уход нескольких топ-менеджеров только усугубил ситуацию. Ларри Пейдж остаётся главой Alphabet, но не отвечает ни на какие вопросы. Это очень плохо, потому что проведенная реструктуризация до сих пор их вызывает».

«После реорганизации в воздухе повис вопрос: как это всё будет работать. Многие, и я в том числе, не были уверены, что главы отдельных подразделений смогут поддерживать глобальное видение Ларри Пейджа и Сергея Брина, которое те вырабатывали в течение многих лет», — отмечает Леви.

Результаты работы за год

Стоимость акций за год значительно выросла: капитализация Alphabet в феврале 2016 года достигла $550 миллиардов. Но пока почти вся прибыль компании приходится на проекты Google.

По одной из версий, Alphabet также создавался, чтобы «удержать» менеджеров высшего звена. Однако в начале июня 2016 года свой пост покинул руководитель подразделения Nest Тони Фаделл. В середине августа со своей должности ушёл глава Google Ventures Билл Марис.

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

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

Как полагает издание The New York Times, одной из причин конфликта между Урмсоном и Пейджем стала кандидатура нового главы подразделения.

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

Google Fiber

А пока проект, на который Alphabet возлагал большие надежды, не оправдал их. По плану, провайдер Google Fiber должен был к 2016 году набрать 5 миллионов подписчиков. В 2014 году у Google Fiber было 200 тысяч подписчиков.

В связи с этим гендиректор Alphabet Ларри Пейдж принял решение сократить команду Google Fiber в два раза – до 500 человек.

Провайдер Google Fiber приступил к реализации проекта в 2010 году. Компания потратила сотни миллионов долларов на прокладку волоконно-оптических линий связи в ряде городов, чтобы обеспечить скорость подключения к интернету примерно в 30 раз выше среднего показателя по США. Однако после шести лет развития сети было решено вместо кабелей использовать на «последней миле» беспроводные системы, писали «Ведомости» со ссылкой на The Wall Street Journal.

Это коснется ряда подключаемых сейчас к проекту городов, в том числе Лос-Анджелеса, Далласа и Чикаго. В Сан-Хосе (Калифорния) и Портленде (Орегон) проект приостановлен. В Google Fiber также сообщили, что запуск их сервиса в Пало-Альто и окрестных городах откладывается по меньшей мере на полгода.

Более тысячи городов подали заявку на подключение к Google Fiber, а в ноябре 2012 года этот сервис начал работать в Канзас-Сити. Гендиректор Google Эрик Шмидт заявлял, что Google Fiber – «не просто эксперимент, а реальный бизнес» и что компания решает, куда должна быть направлена его дальнейшая экспансия. За шесть лет сервис успел охватить лишь шесть крупных агломераций.

Финансовые показатели проекта Fiber не разглашаются – они включаются в показатели группы подразделений, не относящихся к поиску и объединенных под названием «other bets». В данную группу помимо Fiber входят такие подразделения, как Nest и Verily. Совокупная выручка этих подразделений за последний квартал составила $185 миллионов, а операционные убытки достигли $859 миллионов. Квартальные капиталовложения по всей этой группе составили $280 миллионов, основная их часть пришлась на Fiber.

Alphabet рассчитывает на то, что Fiber будет окупаться за счёт абонентской платы и, косвенно, роста бизнеса онлайн-рекламы. Провайдер продаёт доступ к интернету за $70 в месяц, ТВ-сервис — ещё за $60. В марте 2016 года Fiber обслуживал около 53 тысяч ТВ-зрителей — столько же, сколько и в конце 2015 года, подсчитали аналитики MoffettNathanson. Аналитики полагают, что подключение одного дома к Fiber обходится Alphabet более чем в $500, при этом не все квартиры в домах становятся абонентами.

Проблема с Google Fiber не является единственной для Alphabet. В прошлом году компания прекратила продажу первой версии носимого интеллектуального устройства Glass, а недавно была расформирована команда, занимавшаяся разработкой роботов.

Alphabet и «клуб четырех запятых»

Тем не менее, у Alphabet есть серьезные амбиции, которые сводятся в конечном итоге к росту рыночной капитализации до $1 триллиона.

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

Alphabet доминирует на рынке интернет-рекламы. Позиции компании и перспективы рынка способствуют росту стоимости акций Alphabet.

По прогнозам аналитиков, прибыль компании будет расти до 2018 года. К этому времени капитализация Alphabet может составить $950 миллиардов. Если верить прогнозам, то компания имеет все шансы стать членом «клуба четырех запятых».

По оценкам аналитиков, объем продаж Amazon к 2018 году превысит $28 триллионов, и лишь 5,5 процентов обеспечит электронная коммерция. Ставка сделана на AWS — облачный бизнес Amazon, у которого есть большой потенциал. Корпоративные расходы на инфраструктуру растут, растет рынок и будет расти рыночная капитализация Amazon. Аналитики считают, что компания может достичь оценки в триллион долларов в ближайшее десятилетие.

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

Корпорация Apple отчиталась о падении выручки второй квартал подряд. Главная причина — падение продаж iPhone, в основном на китайском рынке. Выручка за третий финансовый квартал упала на 14,6% по сравнению с аналогичным периодом 2015 года. Если в третьем квартале прошлого года этот показатель равнялся $49,6 млрд, то в 2016-м он опустился до $42,4.

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

Let's block ads! (Why?)