Заверение переписки в СМС, WhatsApp и Viber. Корпоративная почта: архивация входящих и исходящих сообщений

Рассматриваем резервное копирование и создание бекапов с точки зрения организации рабочего процесса

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

Основными тенденциями на 2017-2019 годы мы видим следующие виды резервного копирования:

копирование с любых устройств по принципу “подписки” за каждый гигабайт данных с помощью облачных сервисов, которые через предустановленный в систему агент “заливают” копии в облако. Пример тому –
копирование в облако с помощью Veaam и подобных продуктов (Acronis/Symantec/HP Data Protector). Требует подготовки провайдера, настройки коннектора между облаком провайдера и “наземной” виртуальной средой.
копирование “инхаус” с помощью софтовых решений от производителей NAS систем или выделенных хранилищ корпоративного сектора
распределенный бекап с помощью встроенных в ОС Windows Server решений

Задачи резервного копирования в организации

Резервное копирование информации чаще всего преследует две цели:

сохранить данные для максимально быстрого (disaster recovery), если с ИТ-системой компании произошла авария, ее атаковал вирус и т.д. У таких резервных копий сравнительно небольшой период хранения (чаще всего сутки или двое, потом они перезаписываются более новыми), к данным можно получить доступ очень быстро. Копируются пользовательские и бизнес-данные, а также настройки ОС, прикладного ПО и вся информация, необходимая для восстановления работоспособности системы
создать долговременный архив сведений о деятельности компании, к которому можно обратиться при необходимости получить данные за прошедшие периоды. Такие архивы хранятся долго (месяцы и годы), скорость доступа к ним не особенно важна – обычно не страшно, если получение данных займет несколько дней. Хранятся только бизнес-данные и данные пользователей, нет необходимости хранить какую-либо системную информацию.

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

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

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

Резервное копирование VS Избыточное резервирование

Чтобы оборудование продолжало работать, даже если какой-то отдельный компонент откажет, в него вносится определенная избыточность – «лишние» компоненты или вычислительные ресурсы, которые в обычном рабочем режиме могут показаться ненужными.

Пример избыточного резервирования:

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

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

Распорядок резервного копирования

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

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

Виды резервного копирования в организации

Существуют разные технологии резервного копирования, которые отличаются затратами средств и времени:

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

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

Топология резервного копирования

По своей топологии схемы резервного копирования также различаются.

Децентрализованная схема . Её суть в том, что на каждом сервере и рабочей станции может быть собственное ПО для резервного копирования, работающее независимо от других узлов сети. Все данные выгружаются на какой-либо общий сетевой ресурс, откуда потом попадают в архив или восстанавливаются, при необходимости. Достоинства схемы в том, что она чрезвычайно простая, легко реализуется и обычно не требует дополнительного ПО, копирование выполняется штатными средствами операционной системы или СУБД. Есть и недостатки – сложно установить общую политику резервного копирования и защиты информации, общее для всех программ расписание бэкапов, настраивать и мониторить деятельность каждой из программ придется отдельно, что усложняет администрирование. Поэтому децентрализованная схема резервного копирования подойдет либо для небольшой и несложной сети, либо для случаев, когда централизованную схему невозможно организовать в силу каких-либо ограничений
Централизованная схема – для ее реализации необходимо специализированное клиент-серверное ПО. Серверная часть устанавливается на сервер резервного копирования и централизованно управляет установленными у пользователей программными агентами, которые собирают, копируют информацию о системе или восстанавливают ее из копии. В таком варианте легко настраивать общие политики создания резервных копий, расписание бэкапов, все участники могут работать согласно с общей для компании инструкцией по резервному копированию информации
Централизованная схема резервного копирования без программ-агентов – упрощенный вариант предыдущей схемы, когда серверная часть использует только существующие службы и сервисы (например, собирает данные из специально назначенных общих папок Windows). Схема не очень надежная, в ней есть известная проблема, когда открытые в текущий момент для редактирования файлы не попадают в резервную копию и при сбое системы могут быть утрачены. Поэтому применять ее стоит только на небольших сетях и при условии высокой пользовательской дисциплины
Смешанная схема – сочетание централизованной и децентрализованной. Программы-агенты устанавливаются только на некоторых серверах сети, от остальных устройств данные на эти сервера отправляют их локальные программы, каждая своими средствами. А уже с этих серверов накопленную информацию программы-агенты централизованно соберут, обработают и отправят в общее хранилище.

Место хранения резервных копий

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

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

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

Организационные моменты и человеческий фактор

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

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

Большинство компаний понимают важность создания бэкапов. Но вот беда - представление о том, что должна собой представлять стратегия резервирования данных, имеет не так много компаний. В результате они теряют информацию, клиентов, а значит, и деньги. Еще в 2014 году эксперты информировали о том, что бизнес теряет около $1.7 триллиона долларов в год из-за безвозвратных потерь ценнейших данных, которые почему-то не резервировались. Сейчас этот показатель вырос, поскольку часовой вынужденный простой дата-центра обходится оператору в $50 000 - $80 000. Два года назад часовой простой влек за собой убытки в $40 000 - $60 000.

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

Только в первом полугодии 2016 года было утеряно или похищено в результате осуществления кибератак злоумышленниками 554 миллиона записей. Наиболее распространенная цель взлома - похищение личных данных пользователей. В США наиболее атакуемой сферой оказалось здравоохранение. При этом правительственные органы в первом полугодии 2016 года потеряли максимальное количество данных (речь идет об утерянных или похищенных данных).

При этом за весь 2015 год было утеряно или похищено в результате осуществления кибератак 707,5 миллионов записей. Это, правда, меньше, чем в 2014 году, когда аналогичный показатель составил 1,02 млрд записей.

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

Невесёлая история игрушек

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

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

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

ДТП с участием дата-центра

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

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

В итоге дата-центр простоял без дела около пяти часов, в течение которого ничего не работало. Эти пять часов обошлись компании в $3,5 млн. Немало.

… и ещё несколько печальных ИТ-историй

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

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

А сразу после выхода на рынок игровой консоли Xbox One возросла (и очень значительно) нагрузка на сервера компании. Из-за этого начал сбоить и облачный сервис Windows Azure. В течение целого дня наблюдались проблемы с работой Xbox Live - данные иногда не сохранялись, иногда не загружались, мультиплеер в играх не работал.

В 2015 году пострадала известнейшая компания Vtech, которая производит игрушки и электронные устройства для детей. Тогда кто-то взломал сервера компании, и 4,8 млн записей из базы данных клиентов были похищены. Кроме того, были похищены и данные о 200 000 детей (их имена указывались родителями при регистрации).

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

Уже в этом году стало известно о еще одном случае безответственной работы. В утере данных виновным оказался руководитель небольшой хостинг-компании, которая обслуживала около 1500 клиентов. Марко Марсала (Marco Marsala) в один из загруженных работой вечеров запустил команду rm -rf {foo}/{bar} на всех серверах, причем переменные {foo}/{bar} заданы не были (по ошибке). В итоге удалились все данные со всех серверов.

По неудачному стечению обстоятельств, к серверам были подмонтированы накопители с бэкапами. Все эти данные тоже были стерты. Пострадавший владелец компании спросил у других пользователей, можно ли после запуска команды rm -rf {foo}/{bar} восстановить информацию. Понятно, что ничего хорошего другие пользователи ему не сообщили. В итоге невнимательность привела к тому, что бизнес пришлось закрыть (об этом сообщил все тот же Марсала). Так что делать бэкапы мало, их еще нужно и хранить в надежном месте. В комментариях пользователи указали, что «Если у вас только один бэкап - у вас нет бэкапа», что, собственно, является правдой в большинстве случаев.

И проблемы бывают не только у небольших компаний. К примеру, один из крупнейших в мире банков, Barclays, был пару лет назад оштрафован на несколько миллионов долларов США. Причина - частичная утеря деловой переписки за 10 (!) лет. Компания потеряла данные из-за несовершенства системы хранения данных. Технический сбой – и письма утеряны.

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

Некоторые из них, зайдя в свой аккаунт, не увидели ни писем, ни контактов . Тогда было затронуто, по словам Google, «всего 0,08%» от общего числа пользователей сервиса. Но на тот момент Gmail-ом пользовались 193 миллиона человек, и даже сотые доли процента от этого числа - это население небольшого города. Один из клиентов сервиса тогда жаловался на утерю 17 000 писем - это была вся его деятельность за все время.

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

Причины утери данных и бэкапов в компаниях

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

Отказ носителя

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

Человеческий фактор

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

Программный сбой

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

Аппаратный сбой

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

Отказ сети

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

Частные лица ничем не лучше компаний (а может, даже и хуже) в отношении создания резервных копий данных. Еще в 2015 году компания Backblaze провела опрос пользователей, в ходе которого обнаружилось, что даже ежегодно полностью копируют свои данные лишь 39% пользователей. Каждый день это делает только 8% респондентов.

В качестве вывода

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

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

Тамара Воротынцева – директор по развитию тренинговой компании «БИЗНЕС ПАРТНЕР» (Москва). Практикующий бизнес-тренер, автор книги «Строим систему обучения персонала» и публикаций в деловых изданиях России, Казахстана и Украины. Создатель интернет-рассылки: «E-mail переписка в бизнесе» на сервере subscribe.ru! Книга является практическим пособием для деловых людей, ведущих активную переписку с клиентами и партнерами. В ней представлены инструменты, которые помогут сделать электронное общение эффективным, оптимальным по времени и результату, максимально соответствующим нормам и правилам, принятым в современном деловом сообществе. Автор дает практические советы, иллюстрирует свои наблюдения случаями из жизни, приводит аргументированные выводы. Текст книги богат узнаваемыми примерами реальной деловой переписки. Автор делится своими наблюдениями, приемами, «хитростями», которые способны существенно повлиять на эффективность и результативность делового электронного письма. Если вы – деловой человек и для вас важно писать оперативно, лаконично, грамотно, в соответствии в правилами хорошего делового тона, – эта книга станет вам надежным помощником.

Книга:

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

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

Если письмо адресовано вам, но содержит в копии других получателей, обязательно используйте при ответе кнопку «Ответить всем» («Reply ALL»)! Это позволит сохранить круг адресатов, который обозначил инициатор переписки.

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

ОБРАТИТЕ ВНИМАНИЕ. ЭТО ВАЖНО!

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

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

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

ОБРАТИТЕ ВНИМАНИЕ. ЭТО ВАЖНО!

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

Что такое электронная почта? В современном деловом мире это:

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

С этих позиций и посмотрим на работу с электронной почтой. Начнём с простого.

Оформление письма

Я пользуюсь почтовым клиентом Mozilla Thunderbird, поэтому буду рассказывать на его примере. Создадим новое письмо и пойдём сверху вниз по списку полей.

Кому. Копия. Скрытая копия

Возможно, кто-то не знает, но «Кому» в Mozilla можно изменить на «Копия» или «Скрытая копия».

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

Неправильно в массовой рассылке указывать получателей через поля «Копия» или «Кому». Несколько раз в год получаю письма, в которых перечислено 50–90 адресатов в поле «Копия». Налицо нарушение privacy. Не всем из твоих адресатов нужно знать, с кем ещё вы работаете по аналогичной теме. Хорошо, если это знакомые между собой люди. А если в списке конкурирующие компании, которым неизвестно друг о друге? Как минимум нужно быть готовым к лишним объяснениям, как максимум - к прекращению сотрудничества с одним из них. Не надо так.

Тема письма

О важности темы письма часто пишут (иногда толково) в своих корпоративных блогах профессиональные сервисы рассылок. Но там чаще всего идёт речь о продающих письмах, где тема письма решает задачу «email должны открыть».

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

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

Итак, как правильно формулировать тему письма?

Ошибка № 1 : только название компании в теме. Например, «Небо» и всё. Во-первых, наверняка вы не один из вашей компании общаетесь с этим контрагентом. Во-вторых, никакого смысла такая тема не привносит, ведь название вашей компании и так видно из адреса. В-третьих, угадайте, как будет выглядеть ваш собственный ящик при таком подходе к переписке? Примерно вот так.

Удобно искать по таким темам?

Ошибка № 2 : кричащий, продающий заголовок. Здорово, если вы умеете писать такие заголовки. Вот только уместно ли применение этих навыков в деловой переписке? Вспомните цель темы делового письма: не продать, а обеспечить идентификацию и поиск.

Текст письма

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

В процессе написания письма мы должны последовательно принять несколько решений.

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

Уважаем время своё и получателя!

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

Обращение . Меня всегда волновал вопрос, к кому обратиться в письме, если получателей несколько. Недавно я писал письмо, обращённое к трём девушкам по имени Анна. Нисколько не сомневаясь, я написал «Здравствуйте, Анна» и не парился. Но так везёт далеко не всегда.

Что делать, если получателей три или даже семь и они не носят одно имя? Можно перечислить по именам: «Добрый день, Родион, Пульхерия, Авдотья и Пётр Петрович». Но это длинно и занимает время. Можно написать: «Здравствуйте, коллеги!».

Я для себя использую правило обращаться по имени к тому, кто стоит в поле «Кому». А к тем, кто в копии, не обращаться вообще. Это правило заодно позволяет точнее определить (одного!) адресата письма и цель этого письма.

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

Почему-то по умолчанию в Mozilla стоит настройка «Установить курсор после цитируемого текста». Рекомендую её поменять в меню «Инструменты» → «Параметры учётной записи» → «Составление и адресация». Должно быть так.

Цель письма . Деловые письма бывают двух видов:

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

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

Неправильно : «Порфирий Петрович, я знаю, кто зарубил старушку».

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

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

Подпись в тексте . Она должна быть. Тем более все почтовые клиенты позволяют настроить автоподстановку подписи, например классическое «С уважением, …». В Mozilla это делается в меню «Инструменты» → «Параметры учётной записи».

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

Напоследок ещё одна фишка тела письма для тех собеседников, кто не любит (не может, не хочет, не имеет времени) отвечать на ваши письма. Укажите в тексте письма умолчание. Например, «Порфирий Петрович, если не придёте меня арестовывать до 12:00 пятницы, то я считаю себя амнистированным». Разумеется, срок должен быть реальным (не стоит текст из примера отправлять в пятницу в 11:50). Получатель должен физически иметь возможность прочитать и принять решение по вашему письму. Такое «умолчание» снимает с вас ответственность за неответ собеседника. Как и всегда, к применению этой фишки нужно подходить разумно. Если человек вовремя и регулярно отвечает на ваши письма, такой ультиматум может его если не обидеть, то немного напрячь или привести к решению не отвечать на письмо прямо сейчас, а заставить вас ждать пятницы.

Вложения

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

Ошибка : огромный размер вложения. Часто приходят письма с размером вложений до 20 МБ. Как правило, это сканы каких-нибудь документов в формате TIFF, с разрешением 600dpi. Почтовая программа корреспондента почти наверняка зависнет на несколько минут в тщетных попытках загрузить предпросмотр этого вложения. И не дай бог получателю попытаться прочитать это письмо на смартфоне…

Лично я такие письма сразу удаляю. Не хотите, чтобы ваше письмо оказалось в корзине до прочтения? Проконтролируйте размер вложения. Рекомендуется, чтобы оно было не более 3 МБ.

Что делать, если превышает?

Попробуйте перенастроить ваш сканер на другой формат и разрешение. Например, в PDF и 300dpi получаются вполне читабельные сканы.
Вспомните про такие программы, как архиватор WinRar или 7zip. Некоторые файлы отлично сжимаются.
Что делать, если вложение огромное и сжать его не получается? Например, почти пустая база бухгалтерии весит 900 МБ. На помощь придут облачные хранилища информации: Dropbox, Google Drive и тому подобные. Некоторые сервисы, например Mail.ru, автоматически преобразовывают огромные вложения в ссылки на облачное хранилище. Но я предпочитаю сам управлять своей информацией, хранящейся в облаке, поэтому автоматизацию от Mail.ru не приветствую.

И ещё одна не совсем очевидная рекомендация про вложения - их имя . Оно должно быть понятным и приемлемым для получателя. Как-то раз мы в компании готовили коммерческое предложение на имя… пусть будет Фёдора Михайловича Достоевского. Я получил от менеджера письмо с проектом КП на согласование, и во вложении был файл с именем «ДляФеди.docx». С менеджером, отправившим мне это, состоялся диалог примерно следующего содержания:

Дорогой менеджер, ты лично готов подойти к этому уважаемому человеку и назвать его в лицо Федя?

Как-то нет, уважаемый же человек, его все по имени-отчеству называют.

Почему же ты вложение назвал «ДляФеди»? Если я прямо сейчас перешлю ему, как думаешь, он купит у нас топоры по этому КП?

Я собирался потом переименовать…

Зачем готовить мину замедленного действия - отказ потенциального клиента - или создавать себе лишнюю работу по переименованию файла? Почему бы сразу не назвать вложение правильно: «ДляФёдораМихайловича.docx» или ещё лучше - «КП_Небо_Топоры.docx».

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

Работа с письмами

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

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

У кого-то могучая сила воли позволяет не отвлекаться на уведомления, а обычным людям лучше не искушать судьбу и отключить их. В Mozillla Thunderbird это делается через меню «Инструменты» → «Настройки» → «Основные» → «При появлении новых сообщений».

Если нет уведомлений, как понять, что пришло письмо?

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

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

Если и будут срочные письма, то отправитель уведомит вас об этом по другим каналам - телефон, SMS, Skype. Тогда вы осознанно зайдёте в почтовый клиент и обработаете срочную почту. Все гуру тайм-менеджмента (например, Глеб Архангельский с его «Тайм-драйвом») декларируют стандарт ответа на email до 24 часов. Это нормальное правило хорошего тона - не ждать от собеседника мгновенных ответов по email. Если же есть срочное письмо, уведомить об этом по более быстрым каналам связи.

Итак, уведомления мы отключили и теперь включаем почтовый клиент по своему расписанию.

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

Я много слышал про систему zero inbox, но, к сожалению, не встречал ни одного человека, применяющего её. Пришлось изобретать свой велосипед. Статьи на эту тему есть на Лайфхакере. Например, « ». Ниже я расскажу о системе zero inbox в моей интерпретации. Буду благодарен, если гуру GTD отметятся в комментариях, дополнят или улучшат описанную систему.

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

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

Можете ответить на него за три минуты? Нужно ли на него отвечать? Да, нужно, и ответ займёт не более трёх минут, тогда отвечайте сразу.
Отвечать нужно, но подготовка ответа займёт более трёх минут. Если пользуетесь планировщиком задач, позволяющим преобразовать письмо в задачу, превратите email в таск и на время забудьте о нём. Я, например, использую совершенно замечательный сервис Doit.im. Он позволяет сгенерировать персональный email-адрес: пересылаешь на него письмо, и оно превращается в задачу. Но если у вас нет планировщика задач, перенесите письмо в подпапку «0_Выполнить».
После быстрого ответа на письмо, превращения его в задачу или простого ознакомления необходимо решить, что делать с этим сообщением дальше: удалить или отправить в одну из папок на длительное хранение.

Вот какие папки для длительного хранения есть у меня.

0_Выполнить. У меня такой папки нет, но если у вас нет планировщика, повторюсь, сюда можно складывать письма, требующие детальной проработки. Эту папку тоже нужно регулярно очищать, но уже с вдумчивым подходом в специально выделенное на это время.
1_Справ. Сюда я складываю письма со справочной информацией: приветственные письма с логинами от различных веб-сервисов, билеты на предстоящие рейсы и так далее.
2_Проекты. Здесь хранится архив переписки по партнёрам и проектам, с которыми есть текущие взаимоотношения. Естественно, для каждого проекта или партнёра заведена отдельная папка. В папку партнёра я складываю письма не только от его сотрудников, но и письма от сотрудников «Неба», связанные с этим партнёром. Очень удобно: при необходимости вся переписка по проекту под рукой за пару кликов.
3_Музей. Сюда я закидываю те письма, которые и удалить жалко, и польза от них неочевидна. Также сюда перекочевывают папки с закрытыми проектами из «2_Проекты». Словом, в «Музее» хранятся первые кандидаты на удаление.
4_Документы. Здесь лежат письма с электронными образцами документов, которые могут пригодиться в будущем для бухгалтерии, например акты сверок от клиентов, билеты по состоявшимся поездкам. Папка во многом перекликается с папками «2_Проекты» и «1_Справ», только в ней хранится бухгалтерская информация, а в папке «2_Проекты» - управленческая. В «4_Документы» - мёртвая информация, а в «2_Проекты» - живая.
5_Знания. Сюда я складываю только действительно полезные рассылки, к которым хочу вернуться через время для вдохновения или поиска решений.

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

Во-вторых, используем фильтры . Раньше я активно применял фильтры, которые по адресу отправителя автоматически переправляли письма в соответствующие папки. Например, письма от юриста перемещались в папку «Юрист». Отказался от такого подхода по нескольким причинам. Первая: письма от юриста в 99% случаев относятся к какому-либо проекту или партнёру, а значит, подлежат перемещению в папку этого партнёра или проекта. Вторая: решил добавить осознанности. Вы сами должны решить, где должно храниться конкретное письмо, а искать необработанные сообщения удобнее только в одном месте - во входящих. Сейчас фильтры использую только для разнесения по папкам автоматических регулярных писем из различных систем, то есть писем, не требующих от меня принятия решений. Фильтры в Mozilla Thunderbird настраиваются в меню «Инструменты» → «Фильтры сообщений».

Итак, при правильном подходе на электронную почту должно уходить от 10 до 60 минут в день в зависимости от объёма переписки.

Да, и ещё одно. Вы ведь уже отключили уведомления о приходе новых писем? ;)

Кто бы мог подумать еще пару десятков лет назад, что наступит время, когда можно будет связаться с любым человеком из любой точки Земного шара за пару секунд? Такое время наступило, заодно подарив гражданам новые возможности для отстаивания своих прав. Ведь теперь заверенные нотариусом СМС-сообщения, а также переписка с помощью сервисов WhatsApp и Viber могут выступать в роли весомых доказательств. Но для чего это нужно?

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

На каких основаниях электронная переписка может стать доказательством?

Согласно статье 55 ГПК РФ, доказательствами считаются сведения, полученные законным путем, которые используются для рассмотрения дела и принятия того или иного решения по этому делу. Но может ли СМС-переписка или чат в WhatsApp стать доказательствами?

Могут, об этом прямо говорит статья 71 ГПК РФ. Согласно ей, к сведениям для рассмотрения дела могут относиться цифровые записи, полученные с помощью средств электронной связи.

Как документируют переписку с помощью СМС, WhatsApp и Viber?

Хотя по законодательству электронная переписка может стать доказательством, не очень понятно, как ее документируют? На самом деле все значительно проще, чем кажется.

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

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

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

Где можно заверить телефонную переписку?

Заверить смс-сообщения, а также переписку в WhatsApp и Viber можно в нотариальной конторе. Для этого позвоните по телефону +7 495 767-12-77 и запишитесь на прием к нотариусу.