Каким образом будет выглядеть типовая схема работы с web: схемы, советы по разработке, примеры

как масштабироваться на постоянно растущем проекте / Блог компании Агентство AGIMA / Хабр

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

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

Рост проекта и сопутствующие сложности

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

Вот основные вызовы, с которыми может столкнуться агентство на таком проекте:

• Проблема масштабирования — перестроение структуры команды при росте объёмов.
• Необходимость понимания продукта и бизнес-задач — без сильной продуктовой аналитики невозможно эффективно работать на крупном проекте.
• Сложная программная и серверная архитектура — рука об руку с ростом объёмов выработки по проекту идёт и рост посещаемости, ведущий к усложнению архитектуры и необходимости использовать highload-решения.
• Высокие требования к качеству.
• Необходимость обеспечивать бесперебойную работу 24×7 и высокая скорость реакции на инциденты в том числе в неурочное время.
• Высокая степень ответственности за остановку продаж.
• Мониторинг и контроль бизнес-показателей.

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

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

Роли на небольшом проекте и зачем нужно масштабирование

Схема ролей выглядит в общем случае следующим образом:

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

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

На проекте две ключевых роли: руководитель проекта (РП) и тимлид.

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

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

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

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

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

Структура менеджерской команды

Одна из самых сложных для масштабирования единиц — РП.
По мере роста проекта имеет смысл внедрять классическую парную схему account manager — project manager, когда один РП берёт на себя клиентский сервис, включая продуктовые вопросы, а второй организует процесс производства внутри компании.

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

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

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

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

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

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

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

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

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

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

• За 10 рабочих дней до начала месяца каждый РП сам выделяет от трех до пяти своих ключевых задач на следующий месяц.
• За 5 рабочих дней до начала месяца GH выделяет из них по две—четыре для каждого менеджера и выставляет сроки: 1 — клиентский срок (50%), 2 — внутренний срок (100%) и вносит в таблицу.

Условия получения бонусов (по итогам месяца):

• Менеджер получает 100% бонусов, если все его задачи выполнены во внутренний срок.
• Менеджер получает 50% бонусов, если хотя бы одна его задача уехала из внутреннего срока, но была выполнена в клиентский срок.
• Ни один из менеджеров не получает бонусы, если хотя бы одна задача из общего списка не была выполнена в клиентский срок.

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

Тестировать не только конечный код — QA-команда

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

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

• QA отвечают за качество продукта и его стилевое и логическое соответствие другим продуктам и в целом принятым на проекте правилам.
• QA отсматривают все артефакты, появляющиеся на проекте: первичную формализацию задачи, прототипы, спецификации, дизайн, и, конечно, тестируют код и вёрстку, пишут тест-кейсы, покрывают имеющийся и новый функционал сеткой автотестов.
• Без валидации материалов QA-командой РП не имеет права запустить в работу следующий этап или направить материалы на приёмку заказчику.

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

Тимлиды — эффективность или взаимозаменяемость?

Уже при вводе второго тимлида на проект сразу же всплывает вопрос — какую схему распределения обязанностей применить?

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

Оба варианта хороши с точки зрения утилизации ресурсов, но несут большие риски с точки зрения взаимозаменяемости.

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

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

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

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

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

Взаимозаменяемость членов команды

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

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

Дизайн-система

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

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

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

Документация

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

Документацию на проектах имеет смысл разделять на 4 типа:

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

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

GIT

Для ускорения подключения новых разработчиков с других проектов компании внедряется стандартный подход к GitFlow. В AGIMA мы используем подход «работа с двумя основными ветками».

Вместо использования ветки master применяются две основные ветки истории проекта: master для релизов и develop для слияния разрабатываемого функционала из веток feature.

Workflow

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

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

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

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

Поддержание осведомлённости членов команды

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

1. Продуктовые встречи

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

2. Инфраструктурные срезы

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

3. Ретроспективы и планирование работ

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

Выводы

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

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

Концепция web-to-print: новая технология или новая арифметика?

Большинство производителей полиграфического оборудования довольно часто говорят о web-to-print как технологии будущего развития полиграфии, использование которой позволит типографиям рассчитывать на высокую эффективность работы. К сожалению, дальше подобных заявлений никаких других комментариев не дается… Попытаемся разобраться, что же такое web-to-print и насколько перспективно использование этой системы?

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

 

 

 

Как работает web-to-print?

Зачастую web-to-print путают с электронными коммуникациями с типографией: «Мы принимаем файлы заказов по Интернету, так что у нас web-to-print давно используется», — так порой заявляют в полиграфических компаниях. Но на самом деле эта технология подразумевает совсем другой подход. Если коротко, то web-to-print — это попытка переложить на заказчика и на систему автоматизации предприятия выполнение большого количества рутинной работы, которая как раз и не является для типографии прибыльной и, как следствие, тормозит эффективность ее работы.

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

• Заказчик заходит на сайт типографии, находит там типовой макет, максимально близко соответствующий представлению о будущем изделии, и скачивает его.
• На основании этого типового макета заказчик создает собственное изделие с учетом прописанных ограничений: количество полос, число используемых цветов, формат издания, возможность создания выкидных полос и т. д.
• Создав таким образом будущий печатный продукт, заказчик заполняет на сайте типографии специальную интернет-форму, в которой нужно указать базовые параметры заказа: тираж, сорт бумаги, ее плотность и т. д. Все эти параметры обычно выбираются из списка доступных, не давая возможности заказчику предложить свой вариант. Как правило, имеется два–три сорта бумаги (офсетная, мелованная глянцевая, мелованная матовая) и несколько плотностей (90, 115, 150, 200, 300 г/м2). Тиражи также бывают нескольких вариантов: 300, 500, 1000, 2000, 5000 экз. Другие тиражи заказать нельзя (ограничения по тиражам нужны для того, чтобы иметь возможность объединять заказы). Кроме того, может быть предложен и набор отделочных операций, который также лимитирован: лакирование (сплошное в линию на печатной машине), ламинирование (с одной или двух сторон), типовая вырубка (например, карманных календарей или сувенирных игральных карт). Как правило, большого разнообразия отделочных операций не предполагается.
• После заполнения формы система автоматически рассчитывает стоимость заказа (на базе типовых изделий это просто) и выдает заказчику либо счет на оплату, либо запускает программу оплаты (терминал работы с кредитными картами). После оплаты заказа клиенту автоматически выдается доступ к FTP-сайту типографии, на который он может загрузить созданное им самим изделие (обычно в формате PDF).
• После загрузки на сайт типографии PDF-файла попадает в систему управления рабочими потокам, где сначала проверяется на соответствие заложенным в типовом изделии параметрам (формату, красочности, вылетам, разрешению изображений и т. д.). Если в загруженном файле все в порядке, то заказчику выдается подтверждение, что заказ принят, и сообщается срок изготовления (впрочем, это может сообщаться и раньше, после введения параметров заказа). Если в заказе будут обнаружены ошибки, то заказчику придет автоматические уведомление о необходимости их исправить. До исправления ошибок заказ в работу не передается.
• Спустя определенное время служба доставки привозит заказчику готовый тираж изделия.

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

---

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

---

Почему это эффективно?

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

• Первое и самое главное: при приеме заказов через Интернет типографии не нужны менеджеры по работе с клиентами. За них эту функцию выполняет интернет-сайт (если, конечно, выполняет). Предполагается, что клиенты сами найдут сайт типографии, сами во всем разберутся и сами разместят заказ. Это, наверное, возможно, но только на ограниченном пространстве. По интернет-сайту сразу можно не разобраться, где территориально находится компания. А если клиент из Владивостока разместит заказ в типографии из Калининграда, то доставка тиража будет непомерно долгой и дорогой. Если система это отследит, то хорошо, а если нет, то доставка может оказаться за счет типографии, и тогда один такой заказ способен пробить большую финансовую дыру в доходах компании. А клиент формально будет прав. Впрочем, это далеко не единственная особенность работы через Интернет. Но важно здесь то, что раз нет менеджеров по работе с клиентами, то нет и затрат на них. А в цене каждого заказа должны быть заложены затраты на ведущего менеджера, величина которых в зависимости от типографии разная и исчисляется в процентах от цены. Пусть это даже 5%, но, убрав менеджера, можно безболезненно снижать цену на эту величину. Помимо этого, для менеджеров нужно иметь хорошее помещение, переговорные комнаты, офис в центре города и т. д. — все это вместе может стоить типографии существенных денег.
• При работе через Интернет типографии не нужны и операторы по приему заказов, задача которых принимать от клиентов файлы заказов, проверять их, корректировать при необходимости, делать спуски полос и т. д. При наличии типовых заказов можно не только переложить часть работы на заказчика (например, внесение заказа в систему), но и избавиться от этой группы сотрудников. Для типовых заказов спуски делаются автоматически, проверка присланных файлов проста и также автоматизирована.
• При автоматической оплате заказов отпадает необходимость в развитой финансовой службе типографии. Заниматься выпиской счетов, оформлением документов, контролем оплаты не нужно, а значит, в финансовом отделе типографии может работать существенно меньше людей. Таким образом, получается экономия не только фонда заработной платы, но и сокращение затрат на офисе и других социальных благах для сотрудников.
• Типографии не нужно иметь большого разнообразия расходных материалов и бумаги. Достаточно приобретать только один проверенный тип триадной краски и только один формат бумаги (возможно даже нестандартный) нескольких утвержденных сортов и граммажа, исходя из которого и рассчитывать все типовые виды продукции. Это позволит сэкономить складские площади и затраты на материалы. А максимально полное использование бумаги позволит снизить ее отходы до минимума, что не только экономически выгодно, но и экологически полезно. Практика некоторых зарубежных типографий говорит о том, что при переходе на технологию web-to-print удается экономить до 12–15% бумаги.
• Наличие минимального количества заранее известных и проверенных расходных материалов и бумаг позволяет лучше отладить технологию производства и полностью избавиться от проблем «плохой бумаги», «невысохшей краски», брака на фальцовке и т. д.
• Пропускная способность типографии сильно повышается. Реально можно добиться 25–30% увеличения производительности за счет того, что все переналадки максимально упрощаются (ради чего в первую очередь все и унифицируется). Формат бумаги используется один и тот же (нет необходимости перестраивать формат), толщина меняется редко (особенно если есть система управления заказами, которая их оптимизирует), переналадки машины, требующие смены краски вообще исключены. То же и с послепечатными процессами: форматы изделий типовые, программы для резки можно сделать заранее, спуски для фальцовки типовые и т. д. При хорошей программной оптимизации заказов можно даже изготавливать последовательно несколько изделий без перестроения послепечатного оборудования (например, можно легко сшить последовательно несколько однотипных буклетов).
• Типографии не нужно иметь «лишнего» оборудования, которое лишь изредка используется для выполнения специальных операций, а в остальное время простаивает. Достаточно будет только минимально необходимого набора производительного автоматизированного оборудования.
• Существенно снижаются ошибки в выполнении заказов. При наличии всего нескольких типовых видов продукции сотрудники привыкают к одним и тем же операциям и меньше в них ошибаются. Следовательно, вероятность появления «запоротых» тиражей снижается. Насколько это повлияет на финансовую экономичность предприятия зависит от текущей величины переделываемых тиражей.
• Вот такая получается «работа по-новому». В некотором смысле концепция web-to-print переносит типографию из «сферы услуг» (изготавливаем все, что захотите) в сферу производства (изготавливаем типовые виды продукции, но с вашей информацией). Именно эта концепция и позволяет по-новому считать и планировать производственный процесс. При изготовлении типовой продукции вполне реально просчитать и нормы времени, и типовые затраты, а значит, намного эффективнее загружать и планировать производство. У типовой продукции всегда четко известна себестоимость, соответственно, можно оптимизировать продажную цену. Таким образом, web-to-print — это полностью новый вид промышленного полиграфического производства. И хотя внешне кажется, что почти ничего не меняется, на самом деле меняется базовый подход: теперь полиграфия — это производство с полностью другой экономикой и другими расчетами. Из практики известно, что промышленно произведенные товары всегда существенно дешевле, чем выполненные мелкосерийно или штучно. Полиграфия всегда была сферой услуг, то есть выполняла уникальное штучное производство. А переведение полиграфических заказов именно в область промышленного производства позволяет заметно снижать на него цену, сохраняя высокий уровень прибыльности. Появляется новая экономическая реальность, новая «арифметика».

---

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

---

Слева: Если представить, что типография, обладающая технологией web-to-print, захочет получать тот же объем прибыли, что и обычная типография, то у нее автоматически образуется весьма немалая величина, на которую можно безболезненно снизить цену.

Справа: Типографии, работающие по web-to-print, зачастую сознательно идут на отказ от всех видов прибыли кроме основной, что дает им возможность иметь весьма существенный запас по снижению цены заказа.

---

Типовые виды заказов

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

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

В советские времена на всю полиграфическую продукцию существовали типовые нормы и стандарты (ТУ и ГОСТы), и отступление от них было практически недопустимо. А формировались эти нормы как раз на основе максимальной эффективности производства. Сейчас это перестало быть нужным, в конце концов, «клиент платит, делаем что заказывает». Однако если типография в добровольном порядке введет типовые нормы на продукцию, то работать ей станет намного легче. Судите сами, если все издания формата «около А4» сделать единого формата, чтобы спуск полос укладывался четко в формат печатного листа бумаги, то печатать станет удобнее и бумагу всегда можно будет заказывать только одного формата. Также и другие виды заказов можно привести к типовым — унифицировать форматы, которые удобно раскладывать на типовые листы; красочность, чтобы избежать печати с дополнительными цветами; оставить только те виды отделки, которые удобно выполнять и т. д. Полосность издания также можно оптимизировать до разумного. Обычно типовые виды рекламных изданий содержат 4, 8 или 16 полос. А вот, например, 12-полосное издание создаст проблемы при производстве и скажется на цене продукции (скорее всего она будет такой же, как и у 16-полосного). Таким образом, можно смело говорить, что оптимизация заказов позволяет работать более эффективно. Однако оптимизацию нужно проводить с учетом возможностей оборудования, которое используется в типографии.

В конечном итоге, настолько ли заказчику нужен именно тот формат, тот объем, та красочность, которые он задумал? Возможно, он вполне согласится с некоторой переделкой своего проекта, благодаря чему изготавливать его будет проще, быстрее и дешевле. Если клиент готов на это пойти, то все многообразие заказов, которое можно себе представить, легко приводится к небольшому набору типовых форматов, типовых объемов и типовой красочности. На этом и построена технология web-to-print. Некоторые зарубежные типографии, работающие по такому принципу, предлагают выполнять, как правило, только очень ограниченный набор изделий: буклет формата Letter объемом 4, 8, 16 полос на скрепке, типовой флаер в один или в два сгиба, листовку, буклет для CD или DVD из 4, 8, 16 полос на скрепке и т. д. Имея список из двух десятков типовых позиций, можно удовлетворить потребности примерно 85% заказчиков, поскольку именно такую продукцию чаще всего и заказывают в рекламных типографиях.

---

Форматные сложности

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

Приведем пример. Допустим, мы печатаем на полуформатной машине и используем типовой лист бумаги формата 62х94 см. В этом случае формат печатного листа будет 62х47 см. С учетом технологических допусков при печати и обрезке формат изделия, который можно стабильно печатать на такой бумаге, составляет 21х29,7 см (стандартный формат А4). А вот если захочется отпечатать изделие формата 22х29,7 см (более квадратное), то сделать это на бумаге данного формата не получится, придется приобретать бумагу следующего типового размера 70х100 см (печатный лист будет 50х70 см). Да, напечатать запланированное изделие удастся, но перерасход бумаги составит около 20% (примерно на такую величину лист 70х100 см больше листа 62х94 см). Плюс к этому добавится еще операция обрезки лишних полей перед фальцовкой или сборкой изделия, которая также войдет в стоимость заказа. При малых тиражах эти перерасходы будут незначительными, а при средних — уже заметными. При печати типового 16-полосного буклета тиражом 2 тыс. экз. переплата только за бумагу составит около 100 долл. Еще некоторую сумму типография возьмет за «хлопоты» с обрезкой. Стоит ли идти по этому пути, каждый решает сам, но как минимум с точки зрения охраны окружающей среды это уже плохое решение.

---

Недостатки системы

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

• Высокая вероятность конфликтов, особенно в нашей стране. Изначально концепция web-to-print подразумевает принцип «что сгрузил в типографию, то и получил». Но в большинстве случаев заказчик с этим не согласится: «У меня на экране все было хорошо, а вы тут брак напечатали…» Менеджер типографии или специалист отдела пре-пресс может отловить недочеты до запуска работы в печать, а при технологии web-to-print предупредить заказчика никто не сможет.
• Заказчики, которые занимаются поиском типографий в Интернете, — это разовые, случайные клиенты. Как правило, они не являются профессионалами в полиграфии и могут создать «шедевр», который после печати будет выглядеть совсем не так, как они себе это представляли, и, естественно, станут предъявлять претензии типографии. И несмотря на указания на сайте, что «заказы печатаются согласно макету и несоответствие ожиданиям — на совести клиента», недовольства все равно будут.
• Печатать с использованием web-to-print можно только сравнительно простую (и, как следствие, дешевую) продукцию. Зарабатывать заметные деньги в этом случае получится только при большом объеме заказов, выйти на который довольно сложно. Кроме того, с таким объемом заказов может справиться только крупная (следовательно, дорогая) типография.
• Отсутствие человеческого фактора. С одной стороны, это достоинство, но с другой — многим заказчикам привычнее решать вопросы с конкретным человеком, а не с безликой системой. И отсутствие такого человека может восприниматься крайне негативно.
• Развитие технологии web-to-print будет неуклонно снижать цены на продукцию, сокращая уровень дохода типографий. В зависимости от того кем является читатель нашего журнала (заказчиком или производителем печатной продукции), эта информация может быть как негативной, так и позитивной.
• Наконец, для обеспечения работоспособности системы web-to-print нужны серьезные инвестиции в управляющее программное обеспечение, причем речь идет не о коробочном решении (купил, установил и работает). Требуются усилия руководства самой типографии по созданию системы на базе неких готовых инструментов. Результат всей работы зависит от того, насколько успешно такая управляющая система функционирует и каковы ее реальные возможности.

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

 

 

images/content/web2print_2_s.jpg

Краткая инструкция о том, как надо работать с web-дизайнером (взгляд дизайнера)

Введение

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

С удовольствием приму критику и выслушаю мнения «другой стороны».

Кто такой веб-дизайнер

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

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

Это в корне не так.

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

Какую информацию надо предоставить исполнителю

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

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

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

Бриф и техническое задание

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

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

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

Прототип — это важно

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

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

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

Стилизация

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

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

Внесение правок

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

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

Дополнительные страницы и файлы

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

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

Выводы

1. Прислушивайтесь к мнению профессионала
2. Уважайте чужой труд и время
3. Заранее обговаривайте ключевые моменты: сроки, стоимость, конечный результат, количество разрабатываемых страниц и элементов. Утверждайте их письменно или по электронной почте (не на словах)
4. Способствуйте работе дизайнера, отвечайте на вопросы, предоставляйте информацию, идите на контакт
5. Относитесь к людям так, как хотите, чтобы относились к вам

Как работает Веб — Изучение веб-разработки

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

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

Клиенты и серверы

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

• Клиенты являются обычными пользователями, подключенными к Интернету посредством устройств (например, компьютер подключен к Wi-Fi, или ваш телефон подключен к мобильной сети) и программного обеспечения, доступного на этих устройствах (как правило, браузер, например, Firefox или Chrome).
• Серверы — это компьютеры, которые хранят веб-страницы, сайты или приложения. Когда клиентское устройство пытается получить доступ к веб-странице, копия страницы загружается с сервера на клиентский компьютер для отображения в браузере пользователя.

Остальные части панели инструментов

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

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

Помимо клиента и сервера, мы также должны уделить внимание:

• Ваше Интернет-подключение: Позволяет отправлять и принимать данные по сети. Оно подобно улице между домом и магазином.
• TCP/IP: Протокол Управления Передачей и Интернет Протокол являются коммуникационными протоколами, которые определяют, каким образом данные должны передаваться по сети. Они как транспортные средства, которые позволяют сделать заказ, пойти в магазин и купить ваши товары. В нашем примере, это как автомобиль или велосипед (или собственные ноги).
• DNS: Система Доменных Имён напоминает записную книжку для веб-сайтов. Когда вы вводите веб-адрес в своем браузере, браузер обращается к DNS, чтобы найти реальный адрес веб-сайта, прежде чем он сможет его получить. Браузеру необходимо выяснить, на каком сервере живет сайт, поэтому он может отправлять HTTP-сообщения в нужное место (см. Ниже). Это похоже на поиск адреса магазина, чтобы вы могли попасть в него.
• HTTP: Протокол Передачи Гипертекста — это протокол, который определяет язык для клиентов и серверов, чтобы общаться друг с другом. Он, как язык, который вы используете, чтобы заказать ваш товар.
• Файлы компонентов: сайт состоит из нескольких различных файлов, которые подобны различным отделам с товарами в магазине. Эти файлы бывают двух основных типов:
  • Файлы кода: сайты построены преимущественно на HTML, CSS и JavaScript, хотя вы познакомитесь с другими технологиями чуть позже.
  • Материалы: это собирательное название для всех других вещей, составляющих сайт, такие как изображения, музыка, видео, документы Word и PDF.

Что же на самом деле происходит?

Когда вы вводите веб-адрес в свой браузер (для нашей аналогии — посещаете магазин):

1. Браузер обращается к DNS серверу и находит реальный адрес сервера, на котором «живет» сайт (Вы находите адрес магазина).
2. Браузер посылает HTTP запрос к серверу, запрашивая его отправить копию сайта для клиента (Вы идёте в магазин и заказываете товар). Это сообщение и все остальные данные, передаваемые между клиентом и сервером, передаются по интернет-соединению с использованием протокола TCP/IP.
3. Если сервер одобряет запрос клиента, сервер отправляет клиенту статус «200 ОК», который означает: «Конечно, вы можете посмотреть на этот сайт! Вот он», а затем начинает отправку файлов сайта в браузер в виде небольших порций, называемых пакетными данными (магазин выдает вам ваш товар или вам привозят его домой).
4. Браузер собирает маленькие куски в полноценный сайт и показывает его вам (товар прибывает к вашей двери — новые вещи, потрясающе!).

DNS

Реальные веб-адреса — неудобные, незапоминающиеся строки, которые Вы вводите в адресную строку, чтобы найти ваши любимые веб-сайты. Эти строки состоят из чисел, например: 63.245.215.20.

Такой набор чисел называется IP-адресом и представляет собой уникальное местоположение в Интернете. Впрочем, его не очень легко запомнить, правда? Вот почему изобрели DNS. Это специальные сервера, которые связывают веб-адрес, который вы вводите в браузере (например, «mozilla.org»), с реальным IP-адресом сайта.

Сайты можно найти непосредственно через их IP-адреса. Вы можете найти IP-адрес веб-сайта, введя его домен в инструмент, как IP Checker.

Пакеты

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

Смотрите также

Благодарность

Фото улицы: Street composing, Kevin D.

В этом модуле

НОУ ИНТУИТ | Лекция | Основы функционирования веб-приложений

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

Как работают веб-приложения

Цель лекции: сформировать концептуальное представление о функционировании веб-приложений.

Веб-приложения – это специальный вид приложений, которые работают в глобальной сети Интернет по протоколу HTTP (см. «Введение в платформу .NET Framework и ASP.NET» ). Как правило, веб-приложения не требуют установки дополнительного программного обеспечения на стороне клиента, а вся логика, в основном, выполняется на стороне сервера. Для отображения пользовательского интерфейса используется браузер – программа, способная распозновать язык разметки HTML (и сопутствующие технологии – таблицы стилей CSS, клиентский скриптовой язык программирования JavaScript и т.д.). Браузер обычно принято называть «тонким клиентом», т.е. клиентом, который содержит минимальное количество бизнес-логики.

Давайте разберемся в том, как функционирует любое веб-приложение. Необходимые компоненты для работы пользователя с веб-приложением – браузер (тонкий клиент), веб-сервер (серверная часть), протокол взаимодействия клиента и сервера (HTTP) и язык разметки для создания документов (HTML). Основу функционирования веб-сервера и протокола HTTP мы подробнее рассмотрим в следующих лекциях, а пока остановимся на концептуальном представлении. Для того, чтобы веб-приложение стало доступно, его необходимо разместить в рамках веб-сервера (специальная программа, которая обрабатывает запросы из сети). После этого приложение получит свой уникальный адрес в рамках протокола HTTP (например, http://www.myapplication.com/page1.html). Используя этот адрес пользователь может обратиться к приложению. Для этого он должен запустить браузер (клиентское приложение) и ввести в адресной строке адрес приложения. В этот момент браузер сгенерирует запрос к серверу и отправит его, используя протокол HTTP. В момент, когда сервер примет этот запрос, он сможет распознать, что именно требуется от него на основе полученного запроса. Используя эти данные он сгенерирует ответ и отправит его обратно клиенту также используя протокол HTTP. Обычно ответ содержит гипертекстовую разметку HTML, содержащую структуру документа, который передается пользователю. После того, как браузер получит ответ в виде HTML-документа, он немедленно отобразит его пользователю. Таким образом, было совершено взаимодействие клиента и сервера. Зачастую документ HTML содержит ссылки на изображение, другие медиа-файлы, таблицы стилей или клиентские сценарии. В этом случае браузер генерирует еще несколько аналогичных запросов к веб-серверу. Однако, в этом случае веб-сервер передает клиенту уже не HTML-документ, а соответствующие запрашиваемые ресурсы (изображения, таблицы стилей, клиентские сценарии и т.д.).

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

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

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

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

• Веб-приложения исполняются на сервере. Весь программный код исполняется в рамках веб-сервера, а клиенту доставляется уже готовая разметка HTML, которая отображается внутри браузера.
• Веб-приложения не хранят состояния. По-сути, сервер «забывает» про пользователя после того, как обработал его запрос.

Оба этих фактора существенно влияют на процесс разработки веб-приложений. Из-за этого при построении любого веб-приложения приходится решать типичные задачи – способы хранения информации о пользователе, организация сеансов работы пользователя, способы переходов от страницы к странице, механизмы оптимизации эффективности (например, кэширование) и др. При реализации каждого веб-приложения разработчику придется столкнуться с этими проблемами и решить их. Поскольку набор этих задач является достаточно стандартным и одинаково решается для большинства веб-приложений, то его реализация вынесена в отдельные технологии, которые называются технологиями для разработки веб-приложений. К таким технологиям относятся технология Microsoft ASP.NET, PHP, Ruby on Rails и др. В них, фактически, содержатся все компоненты, необходимые для реализации веб-приложений и учитывающие их специфику. Далее в рамках данного курса мы будем рассматривать разработку веб-приложений с позиции платформы Microsoft ASP.NET.

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

Краткие итоги

Веб-приложения работают на сервере и исполняются в рамках веб-сервера (специальной программы, обрабатывающей запросы). Взаимодействие клиента и сервера осуществляется про протоколу HTTP в рамках схемы «запрос-ответ». Вся логика веб-приложения размещается на сервере. Из-за этого появляются дополнительные проблемы при разработке веб-приложений. Настольные приложения имеют более богатый пользовательский интерфейс, но веб-приложения легче разворачивать и обновлять (особенно, если имеется большое количество рабочих мест). Пользовательский интерфейс веб-приложений может стать более интерактивным, если использовать дополнительные инструменты – клиентские сценарии JavaScript, а также приложения Silverlight, Flash и др.

корреляции «из коробки». Часть 2. Схема данных как отражение модели «мира» / Блог компании Positive Technologies / Хабр

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

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

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

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

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

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

Возникает вопрос: возможно ли выделить типовые схемы для взаимодействий, которым бы удовлетворяли любые события, создаваемые всеми возможными ИТ и ИБ-источниками? Если да, то как выглядят эти схемы?

Для поиска ответа на эти вопросы необходимо обратиться к аналитике и постараться проанализировать как можно больше уже разработанных и функционирующих в SIEM-решениях правил нормализации для выявления общих закономерностей. В рамках таких работ удалось провести анализ более 3000 правил нормализации от более чем 100 различных источников из таких решений, как Positive Technologies MaxPatrol SIEM и Micro Focus ArcSight. В результате анализа были получены следующие выводы:

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

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

• Субъект. Сущность, оказывающая воздействие на объект. Например, Пользователь, меняющий ключ реестра, либо хост с IP 10.0.0.1, отправляющий пакет на хост с IP 20.0.0.1.
• Объект. Сущность, на которую оказывает воздействие Субъект.
• Источник. Как правило, хост, который регистрирует взаимодействие Субъекта с Объектом и порождает само событие. К примеру, Источником будет являться межсетевой экран, зафиксировавший передачу пакетов от хоста — Субъекта с IP 10.0.0.1, хосту — Объекту c IP 20.0.0.1.
• Передатчик. Есть случаи, когда SIEM получает события не напрямую с источника, а с промежуточного сервера, через который данные события проходят. Самый просто пример — промежуточный syslog-сервер. Пример посложнее — когда Передатчиком может быть сервер управления, например, Kaspersky Security Center. В этом случае Источник — конкретный агент Kaspersky Endpoint Security.

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

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

Уровень сети

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

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

Основные схемы взаимодействия

Схема 1.Полная схема взаимодействия

В рамках данной модели в событии, поступившем на вход SIEM, можно выделить все основные сущности: Субъект, Объект, Источник, Передатчик. На схеме взаимодействия Субъект воздействует на Объект. Это воздействие регистрирует (наблюдает) Источник и порождает событие. Событие от Источника поступает в Передатчик и с него попадает в SIEM.

Событие ниже фиксирует разрешение сетевого взаимодействия между хостами межсетевым экраном Stonesoft (ныне — Forcepoint), при этом само событие поступает в SIEM не напрямую, а от промежуточного syslog-сервера.

Здесь:
40.0.0.1 — Передатчик (промежуточный syslog-сервер),
30.0.0.1 — Источник (нода межсетевого экрана),
10.0.0.1 — Субъект (отправляющий UDP-пакеты),
20.0.0.1 — Объект (получающий UDP-пакеты).

Схема 2.Схема прямого сбора без передатчика

Далеко не всегда в схеме взаимодействия есть Передатчик. Как правило, он присутствует, когда для передачи событий используется промежуточный сервер (например, syslog-сервер), или когда у решения, с которого собираются события, есть централизованная система управления — например, Kaspersky Security Center, Check Point Smart Console или Cisco Prime. По этой схеме события попадают в SIEM напрямую из Источника. Большая часть всех событий описывается именно этой схемой. Кстати, пример такого события можно увидеть в схеме 1, если бы в ней отсутствовал промежуточный syslog-сервер и мы получали события напрямую от межсетевого экрана.

Здесь:
30.0.0.1 — Источник (нода межсетевого экрана),
10.0.0.1 — Субъект (отправляющий UDP-пакеты),
20.0.0.1 — Объект (получающий UDP-пакеты).

Схема 3. Взаимодействие с множеством Объектов

Эта схема взаимодействия на уровне сети встречается достаточно редко и, как правило, характерна для событий сетевого оборудования. В схеме один Субъект взаимодействует со множеством Объектов, подобное взаимодействие присутствует в событиях, описывающих multicast, unicast или broadcast рассылки.

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

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

Здесь:
30.0.0.1 — Источник (IGMP Relay сервер),
10.0.0.1 — Субъект (запрашивающий принадлежность к группе),
224.0.0.252 — Объект (групповой адрес).

Вырожденные схемы

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

Схема 4. Взаимодействие без Объекта

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

В примере показано, как сервер управления Symantec Management Server фиксирует, что управляемый им агент Symantec Endpoint Protection обнаружил вредоносный файл на своем узле.

Здесь:
30.0.0.1 — Источник (Symantec Management Server),
10.0.0.1 — Субъект (агент Symantec Endpoint Protection).

Схема 5. Совмещение роли Субъекта и Объекта в Источнике

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

В данном примере коммутатор на базе Cisco IOS сообщает, что его интерфейс перешел в статус UP.

Здесь 30.0.0.1 — Источник (коммутатор).

Уровень приложений

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

Большая часть всех типов событий имеет в своем составе взаимодействия одновременно на уровне сети и уровне приложений. Однако, отметим, что события, генерируемые непосредственно прикладным ПО, например, 1С: Предприятие, Microsoft SQL Server или Oracle Database, могут содержать в себе исключительно взаимодействия уровня приложений.

Кроме того, на уровне приложений появляется дополнительная сущность Ресурс.

Ресурс — промежуточная сущность, через которую Субъект оказывает влияние на Объект без прямого взаимодействия. Например, предоставление пользователем Alex прав на доступ к файлу MyFile пользователю Bob. Здесь Alex — Субъект, Bob — Объект, MyFile — Ресурс. Обратите внимание, в данном примере Alex напрямую не взаимодействует с Bob-ом.

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

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

Схема 6. Взаимодействие через ресурс

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

В примере представлена запись из журнала аудита СУБД Oracle Database. В нем зафиксирован процесс отзыва роли у пользователя.

Здесь:
«ALEX» — Субъект (имя пользователя, который отзывает роль),
«BOB» — Объект (имя пользователя, у которого отзывают),
«ROLE» — Ресурс (имя отзываемой роли).

Схема 7. Взаимодействие с множеством ресурсов

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

В примере решение по защите виртуальных сред Код Безопасности vGate фиксирует добавление в набор новых политик.

Здесь:
«admin@VGATE» — Субъект (имя пользователя, изменяющего набор политик)
«base» — Объект (набор политик)
«Установка и поддержка целостности файловой системы», «Проверка настроек SNMP-агента», «Запрет автоматической установки VMware Tools» — Ресурсы (имена добавленных политик)

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

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

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

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

• Параметры самого канала — «трубу»,
• Передаваемые по этой «трубе» данные.

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

Рассмотрим пример события, которое содержит данные о канале взаимодействия. Здесь представлено событие с системы управления процессами идентификации и контроля доступа — Cisco Identity Services Engine (ISE), фиксирующее сетевую сессия пользователя в рамках процедуры аккаунтинга (учет).

Здесь:
«Acct-Session-Id=1A346216», «Acct-Session-Time=50», «Service-Type=Framed», «Framed-Protocol=PPP» — параметры канала коммуникации,
«Acct-Input-Octets=43525», «Acct-Output-Octets=122215», «Acct-Input-Packets=234», «Acct-Output-Packets=466» — параметры переданных по каналу данных.

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

Здесь мы видим событие от межсетевого экрана — Cisco Adaptive Security Appliance (ASA), в котором зафиксировано исходящее TCP-соединение.

В примере отчетливо видно, что внутри одного события присутствуют сущности уровня сети и уровня приложений. На уровне сети — схема взаимодействия Субъекта и Объекта, которое фиксируется Источником. Передатчик отсутствует.

Здесь:
30.0.0.1 — Источник (Cisco ASA),
10.0.0.1 — Субъект (адрес того, кто подключается),
20.0.0.1 — Объект (адрес того, к кому подключаются).

На уровне приложений — простая схема, в которой присутствуют только Субъект и Объект:
«ALEX» — Субъект (имя пользователя, который подключается),
«BOB» — Объект (имя пользователя, к которому подключаются).

Также в этом событии присутствует описание канала передачи данных, но отсутствует описание самих данных:
«TCP» — протокол, на основе которого создан канал,
«136247» — идентификатор сессии канала.

Как могут помочь выделенные нами типовые схемы взаимодействия?

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

Таким, образом, модель «мира», которая строится в SIEM и представляется набором полей (схемой), должна содержать разделы для описания:

1. На уровне сети:
   
   • Субъекта;
   • Объекта;
   • Источника;
   • Передатчика;
   • Канала взаимодействия;
   • Данных, передаваемых по каналу.
   
   
2. На уровне приложений:
   
   • Субъекта;
   • Объекта или множества объектов;
   • Ресурса или множества ресурсов.
   
   

Для каждой сущности необходимо определить набор свойств, которые ее однозначно идентифицируют. На уровне сети сущности идентифицируются IP-, MAC- адресами или FQDN. На уровне приложений — именами или ID. Схема должна иметь выделенные поля для хранения этих идентификаторов.

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

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

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

В итоге общая схема, способная описать все множество типовых взаимодействий, выглядит так:

Схема полей, ориентированная на взаимодействия

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

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

---

Цикл статей:

Глубины SIEM: Корреляции «из коробки». Часть 1: Чистый маркетинг или нерешаемая проблема?

Глубины SIEM: корреляции «из коробки». Часть 2. Схема данных как отражение модели «мира» (Данная статья)

Глубины SIEM: корреляции «из коробки». Часть 3.1. Категоризация событий

Глубины SIEM: корреляции «из коробки». Часть 3.2. Методология нормализации событий

Глубины SIEM: корреляции «из коробки». Часть 4. Модель системы как контекст правил корреляции

Глубины SIEM: корреляции «из коробки». Часть 5. Методология разработки правил корреляции

Важные аспекты работы браузера для разработчиков. Часть 1

Автор: Антон Реймер

Статья основана на вебинаре, который я проводил некоторое время назад. Рассчитана она, в первую очередь на тех, кто не знает, как работают браузеры, или тех, у кого есть пробелы в знаниях. Вероятно, здесь будет много очевидного для тех кто не первый день в веб-разработке. Статью я решил разделить на две части. В первой рассмотрим общие принципы работы браузера. Во второй части я акцентирую внимание на некоторых важных моментах: reflow и repaint, event loop.

Что такое браузер?

Браузер — программа, работающая в операционной системе. Большинство браузеров написано на языке C++. Основное предназначение браузера — воспроизводить контент с веб-ресурсов. В качестве веб-ресурса в большинстве случаев выступает html-страница. Это также может быть pdf-файл, png, jpeg, xml-файлы и другие типы. Среди огромного количества браузеров можно выделить самые популярные: Chrome, Safari, Firefox, Opera и Internet Explorer. Мы рассмотрим браузеры с открытым исходным кодом: Chrome, Firefox, Safari.

Из чего состоит и как работает браузер?

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

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

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

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

Когда мы говорим о браузерных движках, таких как Webkit или Gecko (первый находится «под капотом» у Safari и до 2013 года был у Chrome, второй у Firefox), в первую очередь имеем в виду модуль отображения. Далее мы подробно рассмотрим модуль отображения и более детально разберем, как он работает.

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

Модуль JS Interpreter отвечает за интерпретацию скрипта, и его выполнение. Существует несколько JS-движков. Самые известные это V8 и JavaScriptCore. Важно не путать движок браузера и JS-движок, который работает в модуле JS Interpreter.

Следующий модуль — исполнительная часть пользовательского интерфейса (UI backend). Она отвечает за отрисовку всего на экране и работу пользовательского интерфейса.

Последний модуль — хранилище данных. Браузеру нужно где-то хранить данные, обычно для этого используется оперативная память. Какие данные нужно хранить? Например, кэш, собственные настройки. Также к хранилищу данных можно отнести indexedDB, который появился в стандарте html5 — собственные базы данных браузера.

Модуль отображения

Модуль отображения получает данные от сетевого модуля. Данные поступают пакетами по 8 Кб. Что важно — модуль отображения не ждет, пока придут все данные, он начинает обрабатывать и выводить их на экран по мере поступления. В случае с html-страницами, он начинает их анализировать, происходит парсинг html (это отдельная большая тема, я на ней останавливаться не буду). Главное, что нужно понимать: в результате парсинга у нас появляется DOM-дерево. Также по окончании парсинга срабатывает событие load, которое можно обрабатывать в скрипте. Это значит, что документ готов и скрипт может с ним работать.

DOM-дерево — document object model. По большому счету, «интерфейс», который предоставляет браузер JS-движку для работы с тем или иным html-документом. На основе DOM-дерева происходит конструирование дерева отображения (render tree). Дерево отображения — тоже важная часть модуля отображения. По большому счету, два этих дерева — DOM-дерево и дерево отображения — наиболее важные элементы для разработчика. Дерево отображения во многом повторяет структуру DOM-дерева (далее будет пример, где это будет представлено нагляднее), но имеет некоторые отличия:

1. Дерево отображения не содержит скрытых элементов. Если у нас есть html-элемент, у которого прописан display:none, в дереве отображения он присутствовать не будет. При этом, если visibility:hidden, то в дереве отображения он будет. Некоторые DOM-узлы, которые в DOM-дереве представлены как единый узел, в дереве отображения могут быть представлены в виде нескольких. Яркий пример — составной тэг select. Если в DOM-дереве это один узел, в дереве отображение он преобразовывается в минимум три узла. Первый узел отвечает за отображение выбранного элемента. Второй — за выпадающий список с возможными пунктами. И, наконец, третий блок отвечает за стрелочку.
2. Текст в DOM-дереве представлен как простая node. DOM-дереву нет никакого дела до того, что там написано, сколько строк этот текст занимает. В то время, как для дерева отображения — это важно, и текст трансформируется в несколько узлов, в зависимости от того сколько строк он занимает. Это нагляднее рассмотрим чуть позже.

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

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

Предлагаю рассмотреть два браузерных движка: Webkit и Gecko.

Webkit. Модуль отображения получает html и стили. В результате парсинга html возникает DOM-дерево. В результате парсинга CSS возникает дерево правил таблиц стилей (Style Rules). Далее идет важный этап, который называется Attachment, можно перевести, как «совмещение». На этом этапе CSS-стили накладываются на DOM-дерево, в результате чего появляется Render Tree. После чего происходит компоновка дерева. Называется она здесь Layout. И в завершении происходит отрисовка (Painting).

Если посмотреть на Gecko, можно заметить, что схемы очень похожи. Главные отличия — в терминологии. Здесь тоже парсятся HTML, CSS. В результате чего создается DOM-дерево, которое здесь называется Content Model. Парсятся стили, образуется дерево стилей. Этап Attachment здесь называется Frame Constructor, но, по сути, это тоже самое. В результате совмещения образуется дерево отображения, здесь оно называется Frame Tree. Компоновка здесь называется Reflow. А отрисовка называется Painting, так же, как и в Webkit.

Для простоты приравняем некоторые термины:

• Attachment = Frame constructor = Совмещение
• Render Tree = Frame Tree = Дерево отображения
• Layout= Reflow = Компоновка

Пример

Здесь у нас есть теги:

<head>, <p>, есть <div style =” display: none”> и ещё один <div><img src>”…”/></div>

Модуль отображения строит DOM-дерево. В данном случае оно будет выглядеть следующим образом. Есть корневой элемент (он всегда присутствует), называется он documentElement и соответствует тегу html. В этом дереве присутствуют все теги. И заметим, что текст представлен, как [text node]. И DOM-дереву больше ничего о тексте знать не нужно. На основе этого DOM-дерева строится Render Tree.

Пример

Дерево отображения. У него также есть корневой элемент (RenderView), но уже можно увидеть отличия между DOM-деревом и деревом отображения. Во-первых, нет тега head, т. к. он не отображается на экране. Нет <div style =” display: none”>, есть только

 <div><img src>”…”/></div>

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

Пример

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

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

Порядок обработки скриптов и таблиц стилей

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

<html>
<head>
<script src="script1.js"></script>
<script src="http://site.com/script3.js"></script>

<script defer src="script4.js"></script>
<script async src="script5.js"></script>

<link rel="style" src="style.css"></link>
</head>
<body>

...

<script src="script2.js"></script>

</body>
</html>

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

Но при этом браузер продолжает выполнять ориентировочный синтаксический анализ. Что это значит? Браузер все равно смотрит, что следует за скриптом. Если находятся ссылки на внешние ресурсы, которые нужно скачать и загрузить, он подгрузит эти данные, пока выполняется скрипт 1. Сделано это для оптимизации.

При этом скрипт 3 все равно не будет выполняться, пока не выполнится скрипт 1. К моменту, когда скрипт 1 уже выполнится, скрипт 3 уже может быть полностью загружен. Скрипты можно вставлять в теги head и body. Разница в том, что в скрипте 2, в отличии от скрипта 1, практически весь документ уже будет проанализирован.
У скрипта могут быть атрибуты, такие как defer и async. Они похожи, но у них есть отличия:

• Атрибут defer сообщает браузеру, чтобы тот не ждал окончания выполнения скрипта, а продолжал парсинг html-страницы. При этом скрипт 4 выполнится только после того, как весь html-документ будет проанализирован и построено DOM-дерево.
• Атрибут async тоже говорит браузеру, что дальнейший html-документ может быть проанализирован, пока скрипт выполняется. При этом он загружается в параллельном потоке и выполняется сразу после загрузки. Это означает, что он может быть выполнен раньше, чем скрипт1, если последний тоже имеет атрибут async. Т. е. порядок подключения в этом случае не соблюдается.

В случае с defer скрипт 4 всегда выполняется после скрипта 1. С атрибутом async неизвестно, когда он будет выполнен и какая часть документа уже будет проанализирована к этому моменту.

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

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

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

Компоновка окон

Окно = Прямоугольник = Узел дерева отображения

Способ компоновки окна определяется следующими факторами:

• Тип окна (свойство display).
• Схема позиционирования (свойства position и float).
• Размеры окна.
• Внешняя информация (размеры изображения, размер экрана).

Компоновка окон — это этап компоновки дерева отображения. Я думаю многим верстальщикам знакома эта схема, она называется “Box model”. Я не буду подробно на ней останавливаться.

При компоновке окон учитываются следующее факторы:

CSS-свойство display. Два основных типа — inline и block. Другие, такие как inline-block table и прочие, появились уже позже. Отличие в том, что display:block, указывает, что ширина прямоугольника будет вычисляться в зависимости от ширины «родителя». А display:inline указывает, что ширина прямоугольника будет вычисляться в зависимости от его содержимого. Если в элементе два слова, ширина прямоугольника будет равна ширине, необходимой для вывода этих слов. Inline-элементы выстраиваются друг за другом. А блочные элементы — друг под другом.

Следующее, что влияет на компоновку элемента, — свойства position и float. Position по умолчанию static, при этом прямоугольник идет в стандартном потоке компоновки. Также есть position:relative и position:absolute. Position:relative указывает, что прямоугольнику выделяется место в стандартном потоке компоновки. При этом позиция элемента может быть сдвинута относительно этого места: влево, вправо, вверх, вниз с помощью соответствующего свойства.

Абсолютное позиционирование, к которому относится position:absolute и position:fixed, указывает, что элемент выходит за пределы своего прямоугольника из общего потока компоновки. Остальные прямоугольники его не учитывают. Он также не учитывает соседние элементы. Координаты его вычисляются относительно корневого элемента страницы, либо относительно предка, у которого position не static. Размеры же вычисляются тоже относительно родителя. Также на позиционирование влияет свойство float. Оно указывает, что наш прямоугольник идет в стандартном потоке, но при этом занимает либо крайнюю левую, либо крайнюю правую позиции. При этом все остальные прямоугольники «обтекают» этот элемент.

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

В Firefox модуль отображения работает в одном потоке. Он един на весь браузер. В Chrome все немного иначе: модуль отображения и поток выполнения у каждой вкладки свои.

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

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

Как будет выглядеть ваш сайт? — Изучите веб-разработку

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

Перво-наперво: планирование

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

Для начала вам нужно ответить на следующие вопросы:

1. О чем ваш сайт? Вам нравятся собаки, Нью-Йорк или Pac-Man?
2. Какую информацию вы представляете по этому вопросу? Напишите заголовок и несколько абзацев и подумайте об изображении, которое вы бы хотели показать на своей странице.
3. Как выглядит ваш веб-сайт, простым высокоуровневым языком? Какой цвет фона? Какой шрифт подходит: формальный, мультяшный, жирный и громкий, тонкий?

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

Набросок вашего дизайна

Затем возьмите ручку и бумагу и примерно набросайте, как вы хотите, чтобы ваш сайт выглядел. Для вашей первой простой веб-страницы набросать особо нечего, но вы должны иметь привычку делать это сейчас. Это действительно помогает — вам не обязательно быть Ван Гогом!

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

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

Выбор активов

На этом этапе хорошо начать собирать контент, который в конечном итоге появится на вашей веб-странице.

Текст

У вас все еще должны быть абзацы и заголовок из ранее.Держите их под рукой.

Цвет темы

Чтобы выбрать цвет, перейдите в палитру цветов и найдите нужный цвет. Когда вы нажимаете на цвет, вы видите странный шестизначный код, например # 660066 . Это называется шестнадцатеричным кодом (сокращенно от шестнадцатеричного) и представляет ваш цвет. Скопируйте код в безопасное место.

Изображения

Чтобы выбрать изображение, перейдите в Google Images и найдите что-нибудь подходящее.

1. Когда вы найдете нужное изображение, нажмите на него, чтобы увеличить его.
2. Щелкните изображение правой кнопкой мыши (Ctrl + щелчок на Mac), выберите Сохранить изображение как … и выберите безопасное место для сохранения изображения. Или скопируйте веб-адрес изображения из адресной строки браузера для дальнейшего использования.

Обратите внимание, что большинство изображений в Интернете, в том числе в Картинках Google, защищены авторским правом. Чтобы снизить вероятность нарушения авторских прав, вы можете использовать фильтр лицензий Google. Нажмите кнопку Tools , а затем — соответствующую опцию Usage rights , которая появится ниже.Вам следует выбрать такой вариант, как С меткой для повторного использования .

Шрифт

Для выбора шрифта:

1. Перейдите в Google Fonts и прокрутите список вниз, пока не найдете тот, который вам нравится. Вы также можете использовать элементы управления справа для дальнейшей фильтрации результатов.
2. Щелкните значок «плюс» (Добавить в) рядом с нужным шрифтом.
3. Нажмите кнопку «* Семейство выбрано» на панели внизу страницы («*» зависит от того, сколько шрифтов вы выбрали).
4. Во всплывающем окне вы можете увидеть и скопировать строки кода, которые Google предоставляет вам, в текстовый редактор, чтобы сохранить их на будущее.

В этом модуле

,

Как работает Интернет — Изучите веб-разработку

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

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

Клиенты и серверы

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

• Клиенты — это типичные подключенные к Интернету устройства веб-пользователя (например, ваш компьютер, подключенный к вашему Wi-Fi, или ваш телефон, подключенный к вашей мобильной сети) и программное обеспечение для доступа в Интернет, доступное на этих устройствах (обычно это веб-браузер, например Firefox или Хром).
• Серверы — это компьютеры, на которых хранятся веб-страницы, сайты или приложения. Когда клиентское устройство хочет получить доступ к веб-странице, копия веб-страницы загружается с сервера на клиентский компьютер для отображения в веб-браузере пользователя.

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

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

Помимо клиента и сервера, нам также нужно передать привет:

• Ваше подключение к Интернету : Позволяет отправлять и получать данные в Интернете.По сути, это как улица между вашим домом и магазином.
• TCP / IP : Протокол управления передачей и Интернет-протокол — это протоколы связи, которые определяют способ передачи данных в Интернете. Это как транспортные механизмы, позволяющие оформить заказ, зайти в магазин и купить товар. В нашем примере это похоже на машину или велосипед (или что-то еще, что вы можете обойти).
• DNS : Серверы доменных имен похожи на адресную книгу для веб-сайтов.Когда вы вводите веб-адрес в своем браузере, браузер проверяет DNS, чтобы найти реальный адрес веб-сайта, прежде чем он сможет найти веб-сайт. Браузеру необходимо выяснить, на каком сервере находится веб-сайт, чтобы он мог отправлять HTTP-сообщения в нужное место (см. Ниже). Это похоже на поиск адреса магазина, чтобы получить к нему доступ.
• HTTP : протокол передачи гипертекста — это протокол приложения, который определяет язык, на котором клиенты и серверы могут общаться друг с другом.Это похоже на язык, на котором вы заказываете товары.
• Файлы компонентов : Веб-сайт состоит из множества разных файлов, которые подобны различным частям товаров, которые вы покупаете в магазине. Эти файлы бывают двух основных типов:
  • Файлы кода : Веб-сайты в основном создаются на основе HTML, CSS и JavaScript, хотя вы познакомитесь с другими технологиями чуть позже.
  • Активы : это собирательное название для всего остального, что составляет веб-сайт, например изображений, музыки, видео, документов Word и PDF-файлов.

Так что же именно происходит?

Когда вы вводите веб-адрес в свой браузер (для нашей аналогии это похоже на прогулку в магазин):

1. Браузер переходит на DNS-сервер и находит реальный адрес сервера, на котором находится веб-сайт (вы найдете адрес магазина).
2. Браузер отправляет на сервер сообщение HTTP-запроса с просьбой отправить копию веб-сайта клиенту (вы идете в магазин и заказываете товар).Это сообщение и все другие данные, передаваемые между клиентом и сервером, отправляются через ваше интернет-соединение с использованием TCP / IP.
3. Если сервер одобряет запрос клиента, сервер отправляет клиенту сообщение «200 OK», что означает «Конечно, вы можете посмотреть этот веб-сайт! Вот он», а затем начинает отправлять файлы веб-сайта в браузер в качестве серия небольших фрагментов, называемых пакетами данных (магазин дает вам товары, а вы приносите их домой).
4. Браузер собирает небольшие фрагменты в целую веб-страницу и отображает ее вам (товары прибывают к вам — новые блестящие вещи, круто!).

Объяснение DNS

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

Это называется IP-адресом и представляет собой уникальное местоположение в сети. Однако запомнить это непросто, не так ли? Вот почему были изобретены серверы доменных имен. Это специальные серверы, которые соответствуют веб-адресу, который вы вводите в браузере (например, «mozilla.org «) на настоящий (IP) адрес сайта.

На сайты

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

Объяснение пакетов

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

См. Также

Кредит

Уличное фото: Уличная композиция, Кевин Д.

В этом модуле

,

Как работают схемы Понци | HowStuffWorks

Как мы упоминали ранее, Чарльз Понци не сам изобретал схему. Биограф Понци, Митчелл Зукофф, пишет о его предшественниках, Саре Хоу и Уильяме Франклине Миллере. В 1880-х годах в Бостоне Сара Хау предложила женщинам-инвесторам возможность заработать на Дамском депозите. Она получила полмиллиона долларов от более чем тысячи женщин, использовав часть средств для выплаты другим инвесторам, а остальных вложила в карманы. Пару десятилетий спустя появился Уильям Франклин Миллер и снова попробовал эту схему с еще большим успехом.Он пообещал неслыханные прибыли, и когда он выполнил свои обещания, в него влилось больше инвесторов, которые в общей сложности передали более миллиона долларов, прежде чем он был разоблачен [источник: Zuckoff]. В случае Миллера жертвы были настолько взволнованы успехом своих инвестиций, что решили реинвестировать свои доходы в его схему [источник: Zuckoff].

Ясно, что Понци был не первым, кто реализовал эту схему, и не последним — далеко не всегда. После его трюка в 1920 году по всему миру было разоблачено множество схем Понци.Однако некоторые из них за последние несколько десятилетий были самыми разрушительными. В Албании в 1996 и 1997 годах несколько схем с использованием метода Понци вывели у населения в общей сложности 2 миллиарда долларов (эта сумма равнялась примерно 30 процентам валового внутреннего продукта страны) [источник: Шиллер]. Как только эта схема была раскрыта, вспыхнули беспорядки, в результате которых погибли несколько человек.

До конца 2008 года действующим чемпионом интриганов Понци был Лу Перлман. Помните повальное увлечение бойз-бэндами, которое началось в конце 1990-х? Группы Backstreet Boys и ‘N Sync были двумя из самых популярных музыкальных групп того периода, каждая из которых была создана Перлманом при финансовой поддержке.К 2006 году власти выяснили, что он организовал огромную, длительную схему Понци, которая помогла ему изначально финансировать группы. В течение добрых 20 лет он убеждал других вкладывать средства в несуществующие компании, для которых, как он утверждал, имел страховку FDIC и AIG.

Перлман был приговорен к 25 годам тюремного заключения за мошенничество с инвесторами в размере 300 миллионов долларов. За каждый миллион, который он выплатил, его приговор сокращался на месяц [источник: Sisario]. Если вы думаете, что это большие деньги, приготовьтесь к Берни Мэдоффу.

,

Что такое веб-приложение?

Продажи: +1 (877) 629-2361

• Почему StackPath
  • Наш край
  • EdgeEngine ™
  • сеть
  • Безопасность
• Товары Edge Compute
  • Виртуальные машины
  • Контейнеры
  • Бессерверные сценарии
  • Хранилище объектов
  Пограничные службы
  • CDN
  • WAF
  • Управляемый DNS
  • Мониторинг услуг
  Характеристики
  • Защита от DDoS-атак
  • EdgeRules ™
  • EdgeSSL ™
  • Щит происхождения
• Ресурсы Учиться
  • Служба поддержки
  • Документы API
  • Блог
  • Примеры из практики
  • Клиенты
  • Edge Academy
  Проводить исследования
  • Партнерские программы продаж
  • Программа запуска
  • Ресурсы для разработчиков
• ценообразование
• Продажи: +1 (877) 629-2361

• Авторизоваться Авторизоваться
• Начать Начать

Блог / Объявления

31 мая 2016 г.

,

No related posts.