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

Глава продуктовых решений компании Google Россия, Александра Белых, анонсировала выход на рынок нового инструмент с бета-наименованием «Уникальный охват», призванного помочь маркетологам получать ещё более актуализированную и максимально персонифицированную информацию об охвате. Таким образом это позволит лучше понять его сегментацию и особенности. Из слов представителей Google, в скорейшем времени крупнейшим российским агентствам будет предоставлен доступ к этим данным.
Как пояснила сама глава отдела, новый сервис приобретет сразу несколько этапов функционирования: на первом этапе Google создает кроссдевайсную модель, основанную на пользовательском поведении в рамках всех платформ компании. Затем создается динамическая модель конкретной страны, которая уже может применяться на уровне рекламной кампании.

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

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

Кстати говоря, в дополнении к главному анонсу недели, Google также представила новый русскоязычный портал Thinkwithgoogle.ru, основной миссией которого является трансляция анонсов новых инструментов, исследований и другой полезной информации для паблишеров (рекламодателей).

BYYD • Мобильная рекламная платформа

ссылка на оригинал статьи http://megamozg.ru/post/22276/

Недавно Appcelerator SDK обновился до версии 5.1.0. Появилось много полезных фич.
Список изменений:

Android Marshmallow

Этот релиз поддерживает работу с Android 6.0 и выше. Для его использования в системе должен быть установлен Android SDK level 23. В настройках вашего проекта target SDK должен быть установлен в значение 23 (ранее было 21, Android 5.0/Lollipop)

Node

Начиная с этого релиза, Titanium SDK работает с Node.js версии 4.x (ранее было 0.12.x)

Studio

Этот релиз поддерживает работу с Appcelerator Studio 4.4.0, в списке изменений которой:

• Возможность запоминать ваш логин
• Этот релиз проверит версию node.js (должна быть 0.12.7) или установит версию 4.1.0, если node.js не установлен

Изменения в функциональности

Android

Кнопки AppCompat

Начиная с этого релиза, Titanium SDK будет использовать кнопки из библиотеки AppCompat, что заставит кнопки выглядеть одинаково на всех версиях платформы. Ранее внешний вид кнопок отличался в зависимости от версии Android.

Target SDK

В системе должен быть установлен Android SDK версии 23. Если вы указываете target SDK в файле tiapp.xml, он должен иметь значение 23 (ранее 21).

iOS

Стиль Activity Indicator

Начиная с этого релиза, константы пространства имен iPhone, которые определяли стиль Activity Indicator, считаются устаревшими (deprecated). Для определения стиля Activity Indicator используйте те же константы, но без пространства имен.

События для TabGroup

Этот релиз вводит новые события для элемента TabGroup: selected и unselected. Эти события заменяют устаревшие focus и blur для iOS.

Поддержка User Activity

С этого релиза новый метод Titanium.iOS.UserActivity.isSupported() заменяет устаревшее свойство Titanium.iOS.UserActivity.supported для совместимости с другими API.

Разрешения для устройств

В этом релизе пересмотрен процесс запроса разрешений для платформы для поддержки модели запроса разрешений Android 6.0 и совместимости между платформами iOS и Android. Windows будет добавлен в одном из следующих релизов.

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

• Titanium.Calendar.hasCalendarPermissions
• Titanium.Calendar.requestCalendarPermissions
• Titanium.Contacts.hasContactsPermissions
• Titanium.Contacts.requestContactsPermissions
• Titanium.Geolocation.hasLocationPermissions
• Titanium.Geolocation.requestLocationPermissions
• Titanium.Media.hasCameraPermissions
• Titanium.Media.requestCameraPermissions

Новые методы заменяют устаревшие методы iOS:

• Titanium.Calendar.requestEventsAuthorization
• Titanium.Media.requestCameraAccess

Новый функционал

Android

CardView

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

Reveal Effect

На Android платформе View теперь поддерживают эффект плавного показа/скрытия. Для этого передайте методу .show / .hide в качестве параметра объект { animated: true }.
Эффект поддерживается Android Lollipop и выше.

iOS

3D Touch

Titanium SDK теперь поддерживает Peek and Pop, а так же быстрые действия. Обе функции требуют поддержки 3D Touch и устройства с iOS 9 и выше. Тестирование этой функциональности возможно только на устройстве. Используйте свойство  Titanium.UI.iOS.forceTouchSupported для того, чтобы определить, поддерживает ли устройство 3D Touch.

Peek and Pop предоставляет возможность быстро просмотреть контент приложения нажимая на него, чтобы затем, возможно, переключиться на этот контент. См. Titanium.UI.iOS.PreviewContext API reference для подробностей.

Quick Action предоставляет возможность быстро выполнить какое-либо действие через ярлыки, не заходя в приложение, а просто нажимая на иконку на домашнем экране. См. Titanium.UI.iOS.ApplicationShortcuts API reference для подробностей.

Alert Dialog

С этого релиза, если вы вызываете Aler Dialog со стилем Titanium.UI.iPhone.AlertDialogStyle.PLAIN_TEXT_INPUT или Titanium.UI.iPhone.AlertDialogStyle.SECURE_TEXT_INPUT , вы можете указать свойство placeholder чтобы задать замещающий текст полей ввода и keyboardType/returnKeyType для указания типа клавиатуры.
При использовании Titanium.UI.iPhone.AlertDialogStyle.LOGIN_AND_PASSWORD_INPUT, вы можете  указать замещающий текст как для поля с логином, так и для поля с паролем.

Ресурсы приложения

Для того, чтобы соответствовать принципу App Thinning и соглашению по именованию файлов в iOS, PNG и JPEG файлы вашего проекта будут автоматически добавляться в каталог с ресурсами. Когда пользователь устанавливает ваше приложение, используются только подходящие для него ресурсы.
Для того, чтобы ресурсы попали в приложение, добавьте к их имени @2x и @3x, для retina экранов и iPjone 6 Plus соответственно. Для остальных типов экранов не добавляйте этого суффикса. Так же добавьте суффикс ~iphone для приложений iPhone и ~ipad для приложений iPad. Например:

• pic.png
• pic@2x~ipad.png
• pic@2x~iphone.png
• pic@3x.png

Этот функционал работает только для приложений, собранных на версии SDK 5.1.0 и выше. Для остальных приложений, вам нужно будет добавить поле use-app-thinning со значением true в tiapp.xml (в разlел ios).

<ti:app>   <ios>     <use-app-thinning>true</use-app-thinning>   </ios> </ti:app> 

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

Auto Layout

С этого релиза, ваше приложение может использовать iOS’s Auto Layout engine для расположения элементов.
Активация autoLayout:

<ti:app>   <ios>     <use-autolayout>true</use-autolayout>   </ios> </ti:app>

Потоки для javascript

По умолчанию javascript выполняется в отдельном потоке. С этого релиза вы можете начать выполнять его в главном потоке.
Активация:

<ti:app>   <ios>     <run-on-main-thread>false</run-on-main-thread>   </ios> </ti:app> 

Обратите внимание, эта фича экспериментальная и у нее есть баги:

• TIMOB-19762
• TIMOB-19760

Высота Picker

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

Safari Dialog

Titanium SDK теперь включает в себя модуль ti.safaridialog. Используйте его для того, чтобы просматривать сайты в приложении, похожем на Safari.
Фича требует iOS 9 и выше, и приложение должно быть собрано на XCode 7 и старше.

См. Module API reference для подробностей.

WatchOS Message Callback

С этого релиза если приложение получает сообщение от Watch OS (Titanium.WatchSession.sendMessage()), то вы можете передать в него callback.

Изменения в API

Следующие методы API новые или получили расширенную поддержку среди платформ:

Устаревшие API

ссылка на оригинал статьи http://habrahabr.ru/post/272001/

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

Корреляция в рамках SIEM – сопоставление информации из разных событий с целью последующего реагирования. Способы реагирования – создать новое событие, отправить уведомление администратору по электронной почте или в консоль, выполнить скрипт, завести кейс внутри SIEM, записать информацию в лист(список).
Визуализация – отображение информации из разных событий в виде графиков, диаграм, списков в режиме реального времени или за определенный промежуток времени.
В своей работе я столкнулся с рядом заблуждения со стороны коллег и руководства в понимании, что есть корреляция. Первое – корреляция это сопоставление событий обязательно с разных источников событий. Это абсолютно неверно, т.к. у нас могут быть события разного типа с одного источника, которые так же нужно сопоставлять, как пример события с межсетевого экрана, который при этом является еще VPN шлюзом и системой предотвращения вторжений или события от веб-серверов с разными методами. Второе большое заблуждение – корреляция осуществляется на лету, т.е. время возникновения события небольшое. Третье заблуждение – корреляция нужна только для того, чтобы выявлять инциденты. Четвертое заблуждение – на все можно и нужно реагировать письмом.
Основное заблуждение о визуализации в том, что она нужна только, чтобы показать красивые картинки руководству.
Итак, для чего же на самом деле нужна корреляция, какие в ней основные принципы? Основное – это обогащение интересных событий дополнительной информацией. Как пример, у нас есть голые IP адреса источников, которые раздал DHCP сервер нашим клиентам и мы видим обращения с этого адреса на межсетевом экране к ботнет серверам, но там нет информации о имени пользователя, лезть на DHCP сервер долго и нудно, хочется сразу узнать имя пользователя. Для этого мы забираем логи с рабочей станции для того, чтобы понять какому пользователю или имени машинки назначился IP адрес, который уличили в попытке подключения к ботнету и уже в скореллированном событии видим полную инфомацию о том кто же это сделал. Это пример эффективной корреляции.
Пример неэффективной корреляции – это прежде всего кореляция событий, которые будут часто срабатывать и не будут нести никакой полезной информации, например события о блокировке/обнапужении атаки на IPS совместно с событие о разрешительном срабатывании правила на межсетевом экране. Это правило будет неэффективным в силу того, что будет огромное количество спама, при этом как правило IDS/IPS не отличаются точностью своих сигнатур, а значит дают большое количество ложных срабатываний. Основным критерием неэффективной корреляции является спам неинформативным событиями(уведомлениями).
Еще одной большой головной болью в работе с SIEM является определить, что же важно, а что не очень. Часто данный выбор будет сугубо индивидуальным, но я позволю себе выделить основные моменты. Как мы помним основными угрозами информационной безопасности являются нарушение целостности, доступности и конфиденциальности. При этом, если нарушение конфиденциальности для большинства носит репутационные риски бьет в перспективе на потерю дохода, то нарушение целостности и доступности ударяет здесь и сейчас.
Исходя из этой логики важно быстро реагировать на следующие события: попытки DDoS атак, которые мы можем отслеживать путем анализа событий межсетевых экранов, маршрутизаторов, коммутаторов, netflow, сбором событий о состоянии оборудования с систем ИТ мониторинга (zabbix, nagios и другие), заражение хостов вирусами, брутфорс атаки из интернета к оборудованию на периметре сети, сбои в работе серверов (остановка, запуск служб, изменение прав пользователей, потенциально опасные команды админов), непонятно зачем открывшиеся порты (события со сканеров), взаимодействия с использованием незащищенных протоколов (отслеживаем по портам tftp, telnet и т.п. события на межсетевом экране), остановку в отправке и блокирования логов.
Так же очень эффективным является активное использование сторонних скриптов, которые на определенные события будут уведомлять пользователей о том, что их учетная запись заблокирована в ввиду нарушения политике ИБ в части VPN и т.п., т.е. рутинные задачи, которые часто делают в ручную и где цена ошибки не сильно велика.
Для чего эффективна визуализация? Визуализация очень эффективное средство прежде всего для анализа большого количества однотипных логов, в которых надо наблюдать статистику. Приведу примеры. Хороший кейс для визуализации – это интеграция срабатываний IDS/IPS, МСЭ, netflow с GoogleMaps, а именно визуализация того откуда и куда (если инфраструктура распределенная) у нас идет наибольшее количество запросов, срабатываний сигнатур, трафика, при этом можно всегда настроить так, чтобы при большем числе запросов картинка менялась. Например маленький кругляшок – это от 1 до 100 запросов в час, средний до 1000 и т.д…
Как то не получилось написать много о принципых хорошей корреляции без привязки к внутренним процессам, поэтому часть три будет вместе со второй 🙂
Итак, встречайте часть три.
Основные процессы, которые можно упростить и решать с помощью SIEM.
1. Инвентаризация и управление уязвимостями
Считаю, что это один из ключевых процессов в построении систем ИБ любой организации, скажем так – это шаг 1.
Как реализовывается – отправкой в SIEM результатов сканирований, составление NAT трансляций с логов МСЭ или логов netflow, выгрузка информации из различных каталогов(AD, Sharepoint и т.п.) и ведение списка активов с категоризацией. Сканирования могут осуществляться самописными скриптами, сканера уязвимостей и сетевыми сканерами.
Преимущества – вся нужная информация в одном месте и с ней удобно работать, строить отчеты, визуализировать и сравнивать.
Можно здесь добавить дополнительный скрипт или написать правило, которое будет позволять интеграцию с системой управления инцидентами для последующего закрытия уязвимости или проблемы с безопасностью администраторами.
2. Контроль периметра сети
Визуализация срабатывания правил МСЭ, IDS/IPS, DNS, контроль обращений к C&C серверам и т.п… Данные кейсы должны мониториться аналитиком ИБ в течении дня и должна быть реакция и проактивный разбор инцидента.
Для подобных кейсов является плохой идеей настраивать уведомления по срабатыванию. Для них наиболее эффективен каждодневный анализ в режиме реального времени.
На выходе от анализа подобных кейсов мы повышение эффективности работы всех средств защиты за счет выработки рекомендаций в ходе анализа логов. Мы можем понять на что реагирует средство защиты и нужно ли оно нам, составить список правил МСЭ, которые чаще всего срабатывают, а которые не срабатывали вовсе и оптимизировать работу МСЭ в целом. Мы можем найти зараженные хосты, которые не поймал антивирус.
3. Complience
С помощью SIEM без проблем анализируются несоответствия стандартам безопасности настроек операционных систем, сетевого оборудования, VPN доступа, т.е. любой конфиг, который можно пропарсить и отправить на анализ. Можно сказать, что в целом любой современный сканер умеет это делать, но тут будет немного лукавства, зачастую они обладают излишней функциональностью и плохо справляются с этой функцией и эффективнее использовать самописный скрипт, который выдернет нужные настройки и отправит на анализ в SIEM. Дальше в SIEM можно визуализировать и уведомить о том какие сервера, группы серверов не соответствуют определенным проверкам.
4. Защита от атак из сети интернет.
Самое злободневное и требующее достаточно долгого анализа, чтобы понять что это вот оно – это DDoS атаки, при этом они имеют свойство достаточно серьезно выводить из строя работу системы. Анализ логов МСЭ, веб-серверов, DNS, netflow позволит увидеть резкое изменение количество source адресов и тип трафика, который они отправляют, что может сигнализировать о начале DDoS атаки, что сократит время реакции на нее.
5. Контроль отправки логов.
Это одно из самых важных, что нужно реализовать в рамках SIEM. Эффективно вести список источников, которые отправляют последние 2 часа и уведомлять о истечении времени жизни записи в списке. Так же эффективно смотреть какие логи не прошли через МСЭ по их логам.
Теперь поговорим немного о кадрах.
Как показывает практика в части работы с SIEM есть два больших направления – эксплуатация и развитие первое, а второе непосредственный мониторинг и работы с консолью, т.е. процессинг.
Заниматься этими направлениями должны разные люди, совмещение невозможно.
Что включает в себя эксплуатация и развитие? Прежде всего это поддержание в работе самой SIEM, общение с техподдержкой и т.п… Вторая важная задача – это создание и развитие существующих инструментов для сбора логов и правил корреляции, их тестирование и ввод в эксплуатацию, написание документации по работе с данными правилами и сценариями.
Процессинговая часть включает в себя постановку на мониторинг новых серверов, реагирования на события, анализ логов через средства визуализации, настройку новых средств визуализации и формирование запросов на написание новых правил корреляции.
Важно понимать, что совмещение этих двух ролей приведет к потере эффективности всей инсталляции. Слишком разные роли, которые требуют разных личностных качеств от сотрудника, которые несовместимы в одном человеке.
Вместо заключения хочу сказать, что внедрение SIEM целесообразно в крупных компаниях, у которых есть достаточный бюджет на содержание штата специалистов высокого уровня, которые являются здесь ключевым звеном, а так же наличие средств на покупку дорогого софта выхлоп, от которого будет заметен через несколько лет. Пресловутая корреляция событий, которую всегда так много рекламируют тоже более актуальна для крупных компаний с большим количество серверов и сетевого оборудования. Большинству небольших компаний будет достаточно обойтись обычным лог менеджментом, которое можно чудесно реализовать с помощью open-source решений и WebUI средств защиты, а так же отчетами, которые можно генерировать различными сканерами.

ссылка на оригинал статьи http://habrahabr.ru/post/271999/

Каждый месяц по всему миру происходят десятки, если не сотни, IT-ориентированных конференций, выставок и других мероприятий.

В очередной раз мы собираем все наиболее интересные международные даты этого месяца для того, чтобы представить читателям «Мегамозга» в одном месте.

Woocommerce Meetup 1-го декабря на Манхэттене.

Postseed 2015 состоится в Сан-Франциско 1-го декабря.

2-го декабря в московском офисе Mail.ru митап по фронтенду.

GOTO Berlin со 2 по 4 декабря в Берлине.

Growth Marketing Conference в Сан-Франциско 3 и 4 декабря.

App Promotion Summit 2015 в Берлине 3-го декабря.

DesignerX 3-го декабря в Нью-Йорке.

dotCSS 4-го декабря в Париже.

Geeks On a Plane в этот раз прилетели в ОАЭ, 5 декабря.

И туда же (в Дубаи) прилетает 6-8 декабря Internet of Things World Forum.

dotJS в Париже 7-го декабря.

TechCrunch Disrupt London 7-8 декабря.

Black Hat Executive Summit с 8 по 10 декабря в Скоттсдейле, штат Аризона.

8-9 декабря в Даллассе, штат Техас, Digital Marketing Conference.

Онлайн-конференция Microservices Summit из Берлина 9-11 декабря.

11 декабря пройдёт .NET Москва.

За сим всё, не забудьте подготовить салат «Столичный» к праздничному столу 31-го декабря.

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

ссылка на оригинал статьи http://megamozg.ru/post/22274/

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

Потом все чуть-чуть повзрослели. Появились и начали как-то использоваться redmine/jira/etc, git/svn, jenkins, spinx-docs/rubydoc/doxygen/etc, wiki, unit тесты. Появились подпроекты, стенд подрос. Production сервачков стало несколько. Админ поднял salt/puppet/etc, мониторинг, сидит в своем логове как паук, правит конфиги на salt-master и дергает оттуда state.highstate.

Жизнь

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

Стадий жизненного цикла всего семь.

1. Conceptual design. На этом этапе надо понять, что вообще надо делать.
2. Architectural design. На этом этапе надо понять как это нужно делать.
3. Implementation. Это непостредсвтенно кодинг и unit тестирование.
4. Verification. Проверка того, что все задуманные функции программа выполняет.
5. Validation. Проверка того, что программой таки можно пользоваться. Из предыдущего пункта это внезапно не следует.
6. Ввод в эксплуатацию. В нее обычно входят выкатка релиза, миграция данных, обучение пользователей.
7. Собственно сама эксплуатация.
8. Вывод из эксплуатации

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

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

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

Что может сломаться?

Версии библиотек. Собрались, набросали диаграмку классов, договорились использовать libcrutch. Одна команда давно и долго сидела на libcrutch-1.0, вторая о ней только узнала и скачала из Интернета libcrutch-2.0. А выясниться это только на интеграционном тестировании. Словить bug можно даже на отличиях libcrutch-1.2.14 и libcrutch-1.2.15. А всякие LD_PRELOAD или docker только подливают масла в огонь. Даже если проект весь из себя на микросервисах, в интерфейсы может быть венесен обмен данными, полученными из libcrutch и имеющими в разных версиях разный формат.

Несоответствие версий компонент. Одни пилят libbase, другие libManagementFacade. В процессе выяснилось, что в libbase-1.14.3 есть мелкий но коварный bug. Поговорили, поправили, забыли. Тестировались на libbase-1.14.4, а в релиз ушло libbase-1.14.3.

Изменение конфигурации окружения. Один POST запрос внезапно начал работать долго. Посмотрели, он не такой уж и важный, пусть себе поработает.Увеличили в nginx таймаут ожидания ответа backend’а. Админ на стенде поправил и забыл. Выкатились и опять старые баги ловить, но теперь уже в боевых условиях.

Изменение проектных решений. Начинали делать под Windows, потом прониклись идеями RMS’а, решили перейти на Ubuntu, но до всех решение не довели. Начали собирать, все принесли deb пакеты, а кто-то, кто был в танке, exe’шник.

Потеря значимого для пользователя функционала. Принесли новую версию, долго рассказывали про смену дизайна, про новые фреймворки, про передовые алгоритмы. Пользователи послушали, головой покивали, и сказали: «Это все хорошо, но вы для нас по нашей просьбе формочку делали. Раньше она была пятым подпунктом в третьем пункте меню, где она теперь?» Потеряли на каком-то merge request’е.

Что делать

Программистам очень повезло, что есть git. Основной удар он берет на себя и от них самих требуется совсем чуть-чуть.

1. Индифицировать все компоненты, которые нужны для функционирования проекта, убедиться, что они корректно версионируются. Конфигурация в первом приближении это список компонент и их версий.
2. Понять как обеспечивается перенос конфигурации со стенда в production.
3. Начать управление требованиями. Вообще говоря, управление требованиями это отдельный процесс. В рамках управления конфигурацией нужно убедиться, что для каждого компонента, попавшего в релизный набор, прилагается документация, в которой точно описаны требования, предъявленные к этому компоненту, и их cтатуcы: выполнено, не выполнено, выполнено частично, с оговорками.
4. Да и вообще у каждого компонента должна быть документация, которая описывает что как и зачем он делает.

На этапе завершения conceptual design’а, когда специалисты предметники говорят: «Такая система нам нужна!», — технари в один голос заявляют «Сделаем!», — менеджеры дают отмажку: «Ресурсы выделим — делайте!», — нужно убедиться, что согласованное описание системы из головы экспертов вынуто, на требования порезано и в документацию положено. В процессе разработки это описание будет меняться. Надо убедиться, что описание версионируется. Неплохой вариант, если это текст, забрать его в git

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

На этапе разработки нужно убедиться, что код документируется. Неплохо на модули заводить отдельные документы (в git), которые описывают требования к ним и их особенности поведения. Оставлять много информации в redmine/jira не стоит. После допила большой фичи, перед merge’ом в master, нужно убедиться, что ее описание из task tracker’а корректно перенесено в документацию. Просто потому, что через некоторое время в рамках другой задачи поведение может поменяться и собирать документацию по нескольким задачам будет сложно. Task tracker целостную картину не обеспечивает.

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

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

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

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

Про этап эксплуатации все понятно. Надо просто следовать инструкциям производителя.

На этапе вывода из эксплуатации надо убедиться, что все нужные данные вынуты.

Про сборку и salt/puppet. Это вторая линия обороны (сразу после git’а) Рабочая схема применения примерно такая:

1. Нужно убедиться, что все сторонние пакеты индифицированны: откуда взято, какая версия, какие патчи накладывались. Если какая-то редиска (нехороший человек) приклеивает одинаковые версии на физически разные файлики, его надо убедить, что он не прав, или на всю его продукцию наклеивать дополнительную версию.
2. Если все rpm’ки скидываются в один репозиторий, нужно убедиться, что понятно, какая именно версия будет накатана. Неплохой вариант — иметь скрипт пересборки всего репозитория и наклеивать версию на весь репозиторий целиком. Другой — версию указывать явно в манифесте/sls-файле. Кстати, у puppet’а есть bug, ресурс package не умеет версию понижать. Почему им не стыдно, я не знаю.
3. Все манифесты/sls файлы храняться в git. В pillar для salt или параметры классов для puppet выносится только то, что отличает стенд от продакшена. Такими вещами, например, являются ulr’ы web сервисов, параметры наподобии shared_buffers для postgres, флаги, включающие debug режим. Все остальное безжаластно hard’кодится. Параметры задаются один раз при развертывании стенда и в дальнейшем меняются редко. sls файлы воспринимаются как код, он накатывается на стенд, тестируется и в неизменном виде переносится в production.

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

ссылка на оригинал статьи http://habrahabr.ru/post/271997/