Nextcloud: отказоустойчивый деплой для средних компаний

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

Сегодня мы будем его разворачивать. Я не буду давать полной пошаговой инструкции, но постараюсь упомянуть про ключевые моменты архитектуры, на которые стоит обратить внимание. В частности, разберем балансировку нагрузки, репликацию БД и регламентное обслуживание без прерывания сервиса.
Деплоить будем в отказоустойчивом варианте для небольшой компании в 150-1000 пользователей, но для домашних пользователей тоже пригодится.

Что нужно компаниям?

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

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

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

  1. Киллер-фича с предоставлением доступа вовне в рамках федерации. Можно интегрироваться с аналогичным продуктом у коллег и другой компании.
  2. Предоставление доступов вовне по прямой ссылке. Очень помогает, если вы, например, работаете в полиграфии и надо обмениваться с клиентами большими объемами тяжелых данных.
  3. Редактор документов Collabora, который выполняется на стороне сервера и работает как фронтенд к LibreOffice.
  4. Чаты и видеозвонки. Немного спорная, не совсем стабильная функция, но она есть и работает. В последней версии ее уже стабилизировали.

Строим архитектуру

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

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

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

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

Основные компоненты системы:

  • 1 Балансировщик. Можете взять HAproxy или Nginx. Я рассмотрю вариант с Nginx.
  • 2-4 штуки Application server (web-server). Сама инсталляция Nextcloud с основным кодом на php.
  • 2 БД. В стандартной рекомендованной конфигурации это MariaDB.
  • NFS-хранилище.
  • Redis для кеширования запросов к БД

Балансировщик

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

Обратите внимание, что балансировщик также является точкой терминирования SSL/TLS для ваших клиентов, а общение с бэкендом может идти как по HTTP для доверенных внутренних сетей, так и с дополнительным HTTPS, если трафик до application-сервера идет по общим недоверенным каналам.

База данных

Типовое решение — MySQL/MariaDB в кластерном исполнении в master-slave репликации. При этом у вас активна только одна БД, а вторая работает в режиме горячего резерва на случай аварийного отказа основной или при проведении плановых работ. Можно рассмотреть и вариант с балансировкой нагрузки, но она технически сложнее. При использовании MariaDB Galera Cluster с вариантом master-master репликации нужно использовать нечетное количество нод, но не менее трех. Таким образом минимизируется риск split-brain ситуаций, при рассечении связности между нодами.

Storage

Любое оптимальное для вас решение, которое предоставляет NFS-протокол. В случае высоких нагрузок можно рассмотреть IBM Elastic Storage или Ceph. Также возможно использование S3-совместимого объектного хранилища, но это скорее вариант для особо крупных инсталляций.

HDD или SSD

В принципе, для средних по размеру инсталляций вполне достаточно использования только HDD. Узким участком тут будут iops при чтении из БД, что сильно сказывается на отзывчивости системы, но, при наличии Redis, который кеширует все в RAM, это не будет особой проблемой. Так же часть кеша будет лежать в memcached на application-серверах. Тем не менее, я бы рекомендовал, по возможности, размещать application-сервера на SSD. Веб-интерфейс становится намного отзывчивее по ощущениям. При этом та же синхронизация файлов на десктопных клиентах будет работать примерно так же, как и при использовании HDD для этих узлов.

Скорость синхронизации и отдачи файлов будет определяться уже производительностью вашего NFS-хранилища.

Конфигурируем балансировщик

В качестве примера я приведу простой в базовой конфигурации и эффективный nginx. Да, различные дополнительные failover-плюшки у него доступны только в платной версии, но даже в базовом варианте он отлично выполняет свою задачу. Учтите, что балансировка типа round robin или random нам не подходит, так как application-сервера хранят кеши для конкретных клиентов.
К счастью, это решается использованием метода ip_hash. В таком случае сессии пользователя будут закреплены за конкретным бэкендом, к которому будут направляться все запросы со стороны пользователя. Этот момент описан в документации:

Задаёт для группы метод балансировки нагрузки, при котором запросы распределяются по серверам на основе IP-адресов клиентов. В качестве ключа для хэширования используются первые три октета IPv4-адреса клиента или IPv6-адрес клиента целиком. Метод гарантирует, что запросы одного и того же клиента будут всегда передаваться на один и тот же сервер. Если же этот сервер будет считаться недоступным, то запросы этого клиента будут передаваться на другой сервер. С большой долей вероятности это также будет один и тот же сервер.

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

В конфигурационном файле nginx это описывается следующим образом:

upstream backend {     ip_hash;      server backend1_nextcloud.example.com;     server backend2_nextcloud.example.com;     server backend3_nextcloud.example.com;     server backend4_nextcloud.example.com; }

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

upstream backend {     ip_hash;      server backend1_nextcloud.example.com weight=3;     server backend2_nextcloud.example.com;     server backend3_nextcloud.example.com; } 

В приведенном примере из 5 пришедших запросов 3 уйдут на backend1, 1 на backend2 и 1 на backend3.

В случае, если один из application-серверов откажет, nginx попробует переадресовать запрос следующему серверу из списка бэкендов.

Конфигурируем БД

Подробно Master-Slave конфигурацию можно посмотреть в основной документации.

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

create user 'replicant'@'%' identified by 'replicant_password'; grant replication slave on *.* to replicant; flush privileges;

Затем правим конфиг мастера:

sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf 

В районе блока «Logging and Replication» вносим нужные правки:

[mysqld] log-bin         = /var/log/mysql/master-bin log-bin-index   = /var/log/mysql/master-bin.index binlog_format   = mixed server-id       = 01 replicate-do-db = nextcloud bind-address = 192.168.0.6

На Slave конфигурируем конфиг:

sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf 

В районе блока «Logging and Replication» вносим нужные правки:

    [mysqld]     server-id       = 02     relay-log-index = /var/log/mysql/slave-relay-bin.index     relay-log       = /var/log/mysql/slave-relay-bin     replicate-do-db = nextcloud     read-only = 1     bind-address    = 192.168.0.7

Перезапускаем оба сервера:

sudo systemctl restart mariadb

Далее надо будет скопировать БД на Slave.
На Master выполняем для начала выполняем блокировку таблиц:

flush tables with read lock;

А затем смотрим статус:

     MariaDB [(none)]> show master status;     +-------------------+----------+--------------+------------------+     | File              | Position | Binlog_Do_DB | Binlog_Ignore_DB |     +-------------------+----------+--------------+------------------+     | master-bin.000001 |      772 |              |                  |     +-------------------+----------+--------------+------------------+     1 row in set (0.000 sec)

Не выходим из консоли БД, иначе блокировки снимутся!
Нам понадобится отсюда master_log_file и master_log_pos для конфигурации Slave.
Делаем дамп и снимаем блокировки:

 sudo mysqldump -u root nextcloud > nextcloud.sql 

     > unlock tables;     > exit;

Затем на Slave импортируем дамп и рестартуем демон:

 sudo mysqldump -u root nextcloud < nextcloud.sql sudo systemctl restart mariadb

После этого в консоли настраиваем репликацию:

     MariaDB [(none)]> change master 'master01' to          master_host='192.168.0.6',          master_user='replicant',          master_password='replicant_password',          master_port=3306,          master_log_file='master-bin.000001',          master_log_pos=772,          master_connect_retry=10,          master_use_gtid=slave_pos;

Запускаем и проверяем:

 > start slave 'master01'; show slave 'master01' status\G;

В ответе не должно быть ошибок и два пункта укажут на успешность процедуры:

Slave_IO_Running: Yes Slave_SQL_Running: Yes

Деплоим Application ноды

Есть несколько вариантов деплоя:

  1. snap
  2. docker-image
  3. ручное обновление

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

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

Docker-image — хороший вариант, особенно, если у вас часть инфраструктуры крутится уже на Kubernetes. Та же нода Redis, скорее всего уедет в кластер следом за application-серверами.

Если у вас нет инфраструктуры для этого, то ручное обновление и развертывание из tar.gz вполне удобно и контролируемо.

Не забудьте, что на application-сервера вам потребуется установить веб-сервер для обработки входящих запросов. Я бы рекомендовал связку из nginx + php-fpm7.4. С последними версиями php-fmp ощутимо выросло быстродействие и отзывчивость.

Конфигурирование SSL/TLS

Однозначно стоит рассчитывать на TLS 1.3, если вы делаете новую инсталляцию и нет проблем с пакетами nginx, которые зависят от свежести системного openssl. В частности, 0-RTT и другие плюшки позволяют временами ощутимо ускорить повторное подключение клиентов за счет кеширования. Безопасность также выше за счет выпиливания устаревших протоколов.

Приведу актуальный конфиг для nginx application-сервера, который находится общается с балансировщиком по TLS:

Конфиг nginx

upstream php-handler {  server unix:/var/run/php/php7.4-fpm.sock; }  server {     listen 80;     server_name backend1_nextcloud.example.com;     # enforce https     root /var/www/nextcloud/;     return 301 https://$server_name$request_uri; }  server {     listen 443 ssl http2;     ssl_early_data on; #    listen [::]:443 ssl http2;     server_name backend1_nextcloud.example.com;      # Path to the root of your installation     root /var/www/nextcloud/;     # Log path     access_log /var/log/nginx/nextcloud.nginx-access.log;     error_log /var/log/nginx/nextcloud.nginx-error.log;     ### SSL CONFIGURATION ###         ssl_certificate /etc/letsencrypt/live/backend1_nextcloud.example.com/fullchain.pem;         ssl_certificate_key /etc/letsencrypt/live/backend1_nextcloud.example.com/privkey.pem;         ssl_trusted_certificate /etc/letsencrypt/live/backend1_nextcloud.example.com/fullchain.pem;         ssl_dhparam /etc/ssl/certs/dhparam.pem;          ssl_protocols TLSv1.2 TLSv1.3;         ssl_prefer_server_ciphers on;         #ssl_ciphers "EECDH+AESGCM:EECDH+CHACHA20:EECDH+AES256:!AES128";         ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POL>         ssl_session_cache shared:SSL:50m;         ssl_session_timeout 5m;          ssl_stapling on;         ssl_stapling_verify on;         resolver 8.8.4.4 8.8.8.8;          add_header Strict-Transport-Security 'max-age=63072000; includeSubDomains; preload' always; ### КОНЕЦ КОНФИГУРАЦИИ SSL ###      # Add headers to serve security related headers     # Before enabling Strict-Transport-Security headers please read into this     # topic first.     # add_header Strict-Transport-Security "max-age=15768000;     # includeSubDomains; preload;";     #     # WARNING: Only add the preload option once you read about     # the consequences in https://hstspreload.org/. This option     # will add the domain to a hardcoded list that is shipped     # in all major browsers and getting removed from this list     # could take several months.     add_header Referrer-Policy "no-referrer" always;     add_header X-Content-Type-Options "nosniff" always;     add_header X-Download-Options "noopen" always;     add_header X-Frame-Options "SAMEORIGIN" always;     add_header X-Permitted-Cross-Domain-Policies "none" always;     add_header X-Robots-Tag "none" always;     add_header X-XSS-Protection "1; mode=block" always;      # Remove X-Powered-By, which is an information leak     fastcgi_hide_header X-Powered-By;      location = /robots.txt {         allow all;         log_not_found off;         access_log off;     }      # The following 2 rules are only needed for the user_webfinger app.     # Uncomment it if you're planning to use this app.     #rewrite ^/.well-known/host-meta /public.php?service=host-meta last;     #rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json     # last;      location = /.well-known/carddav {       return 301 $scheme://$host/remote.php/dav;     }     location = /.well-known/caldav {       return 301 $scheme://$host/remote.php/dav;     }      # set max upload size     client_max_body_size 512M;     fastcgi_buffers 64 4K;      # Enable gzip but do not remove ETag headers     gzip on;     gzip_vary on;     gzip_comp_level 4;     gzip_min_length 256;     gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;     gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fon>      # Uncomment if your server is build with the ngx_pagespeed module     # This module is currently not supported.     #pagespeed off;      location / {         rewrite ^ /index.php;     }      location ~ ^\/(?:build|tests|config|lib|3rdparty|templates|data)\/ {         deny all;     } location ~ ^\/(?:\.|autotest|occ|issue|indie|db_|console) {         deny all;     }      location ~ ^\/(?:index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+)\.php(?:$|\/) {         fastcgi_split_path_info ^(.+?\.php)(\/.*|)$;         set $path_info $fastcgi_path_info;         try_files $fastcgi_script_name =404;         include fastcgi_params;         fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;         fastcgi_param PATH_INFO $path_info;         fastcgi_param HTTPS on;         # Avoid sending the security headers twice         fastcgi_param modHeadersAvailable true;         # Enable pretty urls         fastcgi_param front_controller_active true;         fastcgi_pass php-handler;         fastcgi_intercept_errors on;         fastcgi_request_buffering off;     }      location ~ ^\/(?:updater|oc[ms]-provider)(?:$|\/) {         try_files $uri/ =404;         index index.php;     }      # Adding the cache control header for js, css and map files     # Make sure it is BELOW the PHP block     location ~ \.(?:css|js|woff2?|svg|gif|map)$ {         try_files $uri /index.php$request_uri;         add_header Cache-Control "public, max-age=15778463";         # Add headers to serve security related headers (It is intended to         # have those duplicated to the ones above)         # Before enabling Strict-Transport-Security headers please read into         # this topic first.         #add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;" always;         #         # WARNING: Only add the preload option once you read about         # the consequences in https://hstspreload.org/. This option         # will add the domain to a hardcoded list that is shipped         # in all major browsers and getting removed from this list         # could take several months.         add_header Referrer-Policy "no-referrer" always;         add_header X-Content-Type-Options "nosniff" always;         add_header X-Download-Options "noopen" always;         add_header X-Frame-Options "SAMEORIGIN" always;         add_header X-Permitted-Cross-Domain-Policies "none" always;         add_header X-Robots-Tag "none" always;         add_header X-XSS-Protection "1; mode=block" always;          # Optional: Don't log access to assets         access_log off;     }      location ~ \.(?:png|html|ttf|ico|jpg|jpeg|bcmap)$ {         try_files $uri /index.php$request_uri;         # Optional: Don't log access to other assets         access_log off;     } }

Регламентное обслуживание

Не забудьте, что в промышленном окружении требуется обеспечить минимальный и нулевой простой сервиса при обновлении или тем более резервном копировании. Ключевая сложность тут — зависимость состояния метаданных в БД и самих файлов, которые доступны через NFS или объектное хранилище.
При обновлении application-серверов на новую минорную версию особых проблем не возникает. Но кластер все равно надо переводить в mainenance mode для обновления структуры БД.
Выключаем балансировщик в момент наименьшей нагрузки и приступаем к обновлению.

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

sudo -u www-data php /var/www/nextcloud/occ upgrade

После этого включаем балансировщик и подаем трафик на обновленный сервер. Для этого выводим все необновленные application-сервера из балансировки:

upstream backend {     ip_hash;      server backend1_nextcloud.example.com;     server backend2_nextcloud.example.com down;     server backend3_nextcloud.example.com down;     server backend4_nextcloud.example.com down; }

Остальные ноды постепенно обновляем и вводим в строй. При этом occ upgrade уже выполнять не нужно! Нужно только заменить php-файлы и сохранить конфигурацию.

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

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

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

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

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

Если же вы, как и я, горите в аду бесконечного избегания, самобичевания и выгорания, читайте дальше. Я специально все тут пожал gzip-ом, чтобы не прокрастинировать, как обычно, чтение статьи про прокрастинацию, а можно было прочитать пару абзацев и сделать что-то полезное. Пусть даже меня заклюют за "Хабр не тот", отсутствие формул и обзора внушительного списка околонаучной литературы, зато, возможно, еще одним прокрастинатором в мире станет меньше. А может, и двумя.

Почему я ничего не могу сделать?

А кто сказал, что ничего? Наверняка, не можем все, что надо, но можем хоть что-то. Только это «хоть что-то» кажется нам сущей ерундой и мы это не делаем. "Разгоняемся" на Хабре, потом переключаемся на почту, потом на срочный ответ коллеге, потом что-то еще — ну и все на этом. Нужно же выделить время, чтобы сделать "вот эту серьезную штуку", собраться с силами. Но как-то все некогда.

Потом нас накрывает чувство вины, что мы ничего не сделали, и руки начинают опускаться. Да, все это сегодня было вроде бы важно, но задачи "по делу" стоят. Может быть, движимые чувством вины мы все же сделаем что-то из "нужного" — но этого же мало, да? Тяжесть вины усиливается, энергия улетучивается. И мы опять не делаем ничего "по делу".

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

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

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

А что делать?

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

Сделал? Уже хорошо. Вот этого метода вчера не было. Вот эта строчка не была никогда до тебя вот именно тут написана. Залил малюсенький коммит, нарисовал черновик презентации, написал вопросы для будущей статьи? Это уже нечто новое, чего еще час назад не существовало. И стоит себя за это похвалить. Если же ругать себя за слишком мелкие шаги, то это закончится стандартным образом: разочарованием, сползанием в прокрастинацию, оттуда в самобичевание и неспособность сделать сегодня что-то полезное.

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

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

Жизнь и работа — это марафон, а не спринт.

Это все болтовня. Что делать надо?

Использовать 3 простых правила из статьи @salkat в моем вольном изложении:

1) Возвращать убегающие мысли к тому, что нужно сделать. Не заставлять, не лупить себя палками, а придумывать способы включиться в работу: сделать кусочек того, попланировать это. Главное: поменьше насилия над собой, чтобы не сформировать устойчивое отвращение к делу. Важно сделать хоть что-то хотя бы близко. Отколоть простенькую атомарную задачку, как еще советует Дорофеев. Ну скобочки-то можно расставить тут и там, набросать пару тезисов или сделать на форме кнопку-заглушку? Что угодно, что хоть как-то касается нужного проекта.

2) Сосредоточиться на том, что можно сделать вот прямо сейчас с имеющимися ресурсами. Брать задачу по силам и не париться из-за того, что
можно было бы сделать что-то другое. Ловить в себе чувство "а вот можно было бы…" и засовывать туда, откуда оно вышло. Говорить себе: "нет, вот это сейчас самое лучшее, что я могу сделать". Мы — это то, что мы сами себе о себе рассказываем. Так устроен наш ум и грех не использовать это себе во благо.

3) "Снять корону" — не замахиваться на то, чтобы завершить проект сегодня, не взваливать на себя обязательства всех порадовать и никого не обидеть. Радоваться просто тому факту, что в мире появилось что-то, чего еще вчера не было. И это сделали вы. Завтра вы вернетесь в этот файл или документ, а там — ого-го — уже есть какой-то фундамент и можно от чего-то оттолкнуться. И так день за днем тут выростет что-то рабочее: с каждым разом вы будете все больше воодушевляться тем, что начинаете не с пустого места.

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

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

Если не получается делать что-то в нужном направлении (по проекту), сделайте что-то из "списка занятий". Это не план, не список задач, он ничего не навязывает и ничего не заставляет делать. Это шпаргалка на тему "что можно поделать полезного" по разделам: по работе, дома, на диване, у подоконника и т.д. Про нечто похожее недавно писал @KogerCoder.

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

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

" — Не забивайте себе голову тем, что не имеет отношения к настоящему, – сказал Чапаев. – В будущее, о котором вы говорите, надо еще суметь попасть. Быть может, вы попадете в такое будущее, где никакого Фурманова не будет. А может быть, вы попадете в такое будущее, где не будет вас." (с) Виктор Пелевин. "Чапаев и Пустота". 1998.

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

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

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

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

Стажировка для мобильных разработчиков в Redmadrobot

Привет, мобильные! Redmadrobot открывает оплачиваемую стажировку для начинающих iOS- и Android-разработчиков в марте 2021 года, которая пройдёт в самарском офисе. Поможем раскрыть внутреннюю силу джедая и поделимся 11-летним опытом разработки мобильных приложений.

Что будет:

  1. Поможем освоить самые актуальные навыки для разработчика в 2021 году.
  2. С головой погрузимся в материалы из проектов Redmadrobot.
  3. Дадим интересные и сложные задания.
  4. Познакомим с проектными бизнес-процессами и внутренней кухней компании.

«Стажировка в Redmadrobot позволила мне полноценно погрузиться в профессию разработчика мобильных приложений»

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

  • культура менторства: всегда можно «подёргать за рукав» опытных разработчиков и получить ответ на все вопросы;
  • материальная поддержка: можно сфокусироваться на обучении;
  • постоянная прокачка: все открыты и делятся своим опытом и знаниями с окружающими, можно посещать внутренние мероприятия по разным направлениям, а не только по разработке.

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

Cергей Попыванов, iOS-разработчик Redmadrobot.

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

Не буду перечислять всё, что я изучил за три месяца, но, например, если говорить про безопасность, то я здорово прокачался в:

  • моделях угроз и разобрался, как уберечь доверчивых пользователей от них самих;
  • защите соединения между клиентом и сервером;
  • практиках шифрования и хранения данных на устройстве;
  • OWASP Mobile Top-10;
  • root на Android — понял, как с этим жить и писать безопасные приложения;
  • reverse engineering Android-приложений.

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

Очень рад, что в своё время решил стать Android-разработчиком. Надеюсь, многие из вас тоже сделают правильный выбор 😉 Мир, код, Kotlin!

Дима Гавриков, Android-разработчик Redmadrobot.

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

Сегодня открыто восемь мест — по четыре на каждую практику. Лучших стажёров, а может и всех восьмерых, мы пригласим на постоянную работу в Redmadrobot.

Ждём заявки до 12 декабря 2020 года. Результаты прохождения заданий вышлем в ответном письме. Подключайтесь!

Хочу на iOS

Хочу на Android

Если есть вопросы, пишите на l.andriianova@redmadrobot.com — обо всём расскажем.

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

Опыт использования транслятора OberonJS для создания редактора интерактивных моделей

Занимательное дело — создавать образовательные модели. Приятно видеть, что человек понял какой-то сложный принцип в естественных науках или алгоритмах, взаимодействуя с твоей программой. По профессии я биофизик, так что с уравнениями и математикой обычно у меня нет проблем, а вот с инструментарием для создания наглядных интерактивных моделей — прошел достаточно длинный путь. Начинал делать модели в Matlab, там отличные библиотеки для решения уравнений, есть возможность легко строить графики. Недостаток в том, что результатом сложно поделиться, и достаточно сложно сделать что-то выходящее за рамки, предусмотренные разработчиками. Нужно больше свободы. Также пробовал использовать технологию Flash, в те годы технология была ещё актуальна для web, и язык ActionScript позволял делать достаточно занятые интерактивные модели. Однако сам язык программирования ActionScript не соответствовал моим строгим представлениям о гармонии и порядке, а потом и вовсе технология Flash была вытеснена из браузеров новым стандартом HTML5… К тому времени я уже активно программировал модели в среде BlackBox Component Builder. Это швейцарская open-source разработка, достаточно герметично изолированная от операционной системы IDE, которую они разработали на базе операционной системы ETHOS. Графические библиотеки меня вполне устроили, производительность компилятора, скорость выполнения расчётного кода — тоже. И главное, язык Оберон идеально лёг на моё представление о том, сколько вообще язык программирования должен занимать в голове у специалиста предметной области. Не нужны были какие-то лингвистические причуды, было приятно находиться в зоне комфорта и думать о задаче. Однако в 21-веке распространять компилированные приложения, чтобы показать студентам что-то, или просто выкладывать в Интернете модели — очень сложно. Ведь люди просто боятся запускать сторонние приложения, и антивирусы часто дают ложно-положительные срабатывания. Десктоп приложения для науки и производства — отлично, интерактивные модели для просвещения людей — нет.

В 2014 году вместе с проектом Информатика-21 мы проводили IT-конференцию в Москве. Туда приехали специалисты по Оберон-системам со всей России и даже из Белоруссии. Я тогда не поленился взять свою старенькую камеру, и записал большую часть докладов. Из доклада Алексея Веселовского я узнал про транслятор OberonJS. Тезис доклада простой: JavaScript — это субстанция весьма аморфная, так что разрабатывать на нём что-то крупное — головная боль, а вот если JavaScript оформить Обероном, будет существенная экономия на отладке. Оберон в некотором роде среднее звено между блочным программным конструктором LEGO MINDSTORMS и безграничной свободой Си. В общем, сделать можно на нём что угодно, и при этом вероятность «выстрелить себе в ногу» минимальна. Мужики тогда сделали демку, чтобы показать, как это работает. Код из окошка CodeMirror прямо в клиентском браузере транслируется из Оберона в JavaScript и выполняется. Это бы меня не зацепило, если бы Алексей не сделал демонстрацию, как это можно объединить с фреймворком ProcessingJS!

Строгий простой язык + продвинутая графика в HTML5 = идеальная формула для образования, чтобы пользователи не только видели интерактивную графическую модель, но и могли легко понять алгоритмы в её основе. Люблю приводить цитату Сергея Залмановича Свердлова:

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

Модуль «Привет Мир!» на Обероне будет выглядеть следующим образом:

MODULE HelloWorld; IMPORT Log; BEGIN  Log.String("Привет Мир!"); Log.Ln END HelloWorld.	

Синтаксис Оберона очень напоминает язык Паскаль, однако не стоит их путать.

Взяв за основу транслятор OberonJS, я начал экспериментировать, как можно сохранять модули в базе данных, как это отобразить в интерфейсе на сайте. Идея такая, чтобы возможно было хранить код на Обероне в базе данных, загружать в CodeMirror у клиента в браузере, транслировать онлайн и выполнять. Как выглядит интерфейс, который у меня получился, вы можете посмотреть на примере модели самоорганизующейся карты Кохонена. Автор транслятора Владислав Фольц помог сделать систему русификации сообщений об ошибках в коде и вывод точной позиции. В итоге удалось объединить систему хранения модулей с системой учётных записей пользователей и довести сайт до состояния MVP, чтобы получить поддержку моего университета для развития данного гуманитарного проекта.

Набор инструментов для создания моделей свелся к шести модулям: Log для вывода текстовой информации из программы, Math для математических функций, Strings для работы со строками, Draw для рисования, Forms для создания элементов управления и Plot для создания графиков. Последние два модуля пока достаточно сырые, работа над ними продолжается.

Вместо библиотек ProcessingJS, поддержка которых была остановлена, теперь используется библиотека p5.js. Мы оборачиваем вызовы к библиотеке и JavaScript коды в процедуру JS.do, а в остальном — используем синтаксис Оберона. Так как в Обероне запрещено автоматическое преобразование типов, то между REAL и INTEGER преобразование осуществляется процедурами FLOOR и FLT. Чтобы уменьшить вызов явных преобразований, для рисования используется два типа процедур: первые с действительными аргументами, вторые с целыми. При этом, чтобы избежать проблем с размытием линий, для целочисленных вызовов к координатам автоматически добавляется половина пикселя:

MODULE Draw; IMPORT JS; ... PROCEDURE Line*(x0, y0, x1, y1: REAL); BEGIN JS.do("Instance.line(x0,y0,x1,y1)") END Line;  PROCEDURE LineInt*(x0, y0, x1, y1: INTEGER); BEGIN JS.do("Instance.line(x0+0.5,y0+0.5,x1+0.5,y1+0.5);") END LineInt; ... END Draw.

Звездочка * обозначает экспорт процедуры за пределы области видимости модуля. Instance создаётся в момент запуска модуля через процедуру Draw.Start, и необходимые нам процедуры присваиваются, заменяя стандартные колбэки библиотеки p5.js, так как показано на примере процедуры InnerDraw ниже.

MODULE Draw;  TYPE  ProcessingType* = POINTER TO RECORD END;  VAR  Instance: ProcessingType; focus, started: BOOLEAN;  ...  PROCEDURE InnerDraw; BEGIN  IF DrawProc # NIL THEN   TrackMouse;   DrawProc;   IF FormDraw # NIL THEN FormDraw END  END END InnerDraw;  PROCEDURE Start*; BEGIN  ASSERT(~started);  JS.do("let sketchProc = function(p){  p.preload=Preload;  p.draw=InnerDraw; p.setup=InnerSetup;  p.keyPressed=InnerKeyPressed; p.keyTyped=InnerKeyTyped;  p.mousePressed=InnerPressed; p.mouseReleased=InnerReleased;  p.mouseOver=InnerOver; p.mouseOut=InnerOut;  Instance=p;  }");  JS.do("var processingInstance = new p5(sketchProc);");  JS.do("Instance.colorMode(Instance.RGB, 255, 255, 255, 1);");  JS.do("removeSketch = function() { Remove(); }");  focus := FALSE;  started := TRUE END Start;  END Draw.

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

... var Init = function (Log){  function Do(){ 	Log.String("Привет Мир!"); 	Log.Ln(); } Do(); }(Log);

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

MODULE Strings;  IMPORT JS;  PROCEDURE Length* (s: ARRAY OF CHAR): INTEGER; VAR i: INTEGER; BEGIN i := 0;  WHILE (i < LEN(s)) & (s[i] > 0X) DO INC(i) END  RETURN i END Length;  ...

получим результат трансляции:

var Strings = function (JS){  function Length(s/*ARRAY OF CHAR*/){ 	var i = 0; 	i = 0; 	while (true){ 		if (i < s.length && RTL$.charAt(s, i) > 0){ 			++i; 		} else break; 	} 	return i; }

Проверка charAt осуществляется в специальном наборе функций рантайма:

var RTL$ = {     charAt: function(s, index){         if (index >= 0 && index < s.length)             return s.charCodeAt(index);         throw new Error("index out of bounds: " + index);     }, ... }

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

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

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

В перспективе было бы интересно объединить OberonJS с фреймворком Electron.

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

Секретная служба Абвер: интенсивной войне — интенсивный шпионаж

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

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



Традиционно шпионаж делился на две основные ветки, в каком-то плане «специализации»:

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

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

Еще в начале 19 века разведывательные службы Германии заслужено считались одними из лучших в Европе. Во времена Вильгельма Штибера (1818 — 1882), отца немецкой разведки и контрразведки, знаменитого прусского мастера шпионажа, в Пруссии и Франции под его началом уже трудилась целая армия секретных агентов — 12 тысяч. Принято считать, что именно Штибер придал современной секретной службе характер последовательной и преднамеренной жестокости как в военное, так и в мирное время.

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

Английский журналист Рисс Курт охарактеризовал систему, созданную Штибером, как тотальный шпионаж. Тотальный из-за своих 3 принципов:

  • каждый может быть шпионом
  • каждый должен быть шпионом
  • нет тайны, которую нельзя было бы узнать

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

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

В книге «Иностранный шпионаж и борьба с ним в Российской империи 1906 -1914 гг.» В.О. Зверев пишет о том, что главным противником, хорошо разбиравшимся в вопросах шпионажа, выступала Германия. Любопытный факт «внедрения» на земли интересующих держав: с целью окультуривания русского крестьянства с согласия русских императоров немецкие помещики и крестьяне переезжали в Россию. Многие из них селились в пределах приграничных военных округов, где были сосредоточены портовые города, военные крепости и другие объекты, интересные для иностранной разведки. В окрестностях Санкт-Петербурга с населением 2 740 000 человек к 1910 году проживало 93 тысячи немецких поселенцев, а 1 августа 1914 года в рядах русской армии, насчитывавшей около 1 400 000 солдат, служило 300 тыс. немцев. Выходит, что каждый пятый военнослужащий имел германские корни…

Немного истории становления Абвер

С 1889 и по 1944 годы все служебные инстанции и подразделения рейхсвера, а позднее вермахта, предназначенные для ведения контрразведки, шпионажа и диверсионных актов условно называли абвером (в переводе с немецкого — защита). После поражения в Первой мировой Германия на время осталась без военных спецслужб. И вот в 1920 году в составе вооруженных сил была сформирована группа, которая должна была заниматься лишь контрразведкой, а на деле стала разведывательным органом. Официальной датой воссоздания Абвера принято считать 23 марта 1921 года. В 1928 году после объединения с разведывательной службой флота группа была повышена в статусе до отдела. В 1938 году реорганизована в Управление разведки и контрразведки Верховного командования вермахта (ОКВ). О масштабах деятельности страшного ведомства, соткавшего агентурную паутину над множеством стран мира за всю историю его существования, никак лучше говорит лозунг — «Интенсивной войне — интенсивный шпионаж», от успешных широкомасштабных диверсионных операций до превращения Абвера в важнейший инструмент гитлеровской политики. Во время Второй мировой Абвер стал центральным органом ведения разведдеятельности за рубежом и сыграл огромную роль в подготовке и обеспечении успеха гитлеровской агрессии против государств Европы.


Главное здание отделения OКВ в районе Штансдорфа (Германия)


Филиал OKВ в Штансдорфе 1942 год

Разведывательная служба Абвер при адмирале разведчике Вильгельме Канарисе в 1935 — 1944 насчитывала свыше 50 тысяч сотрудников, штатных и нештатных.


Вильгельм Канарис

Аппарат Абвера летом в 1920 году состоял из 2 групп, деятельность которых была направлена против шпионажа и саботажа — Восточный и Западный блоки. В 1921 году в состав группы входили 3 подгруппы (Untergruppe I, Untergruppe II, Untergruppe III). К октябрю 1938 года Центральный аппарат Абвера состоял из 5 главных отделов:

  • Центральный отдел (Z) — административные вопросы, центральный архив и картотека агентов Абвера
  • 1-й отдел (А-I) — шпионаж в иностранных государствах
  • 2-й (А-II) — диверсионно-террористическая деятельность на территории войск противника
  • 3-й (A-III) — военная контрразведка внутри страны и за границей
  • отдел «Аусланд» (Ausland) — сбор разведывательной информации путем изучения иностранной прессы, радиопередач и литературы, обработки сведений, поступавших от германских военных атташе за границей, руководство их разведывательной деятельностью

В систему Абвера входили органы разведки и контрразведки в различных соединениях вермахта, функционировали многочисленные периферийные отделы, называемые «абверштелле». Следуя заявлению начальника отдела «Абвер-2» Эрвина Штольце, Абвер образца 1938 года отличался от германской военной разведки времен первой мировой да и военных разведок большинства европейских стран, так как разведслужбы трех составных частей вермахта (армия, люфтваффе и кригсмарине) были объединены в одном отделе — Абвер-1. Развединформация поступала централизованно, что позволяло "… вести сбалансированную политику развития всех родов войск и способствовало значительному повышению боеспособности вермахта во время войны".

Согласно дневниковых записей Ганса Пикенброка (руководитель отдела «Абвер-1» с 1936 года), существовало несколько агентурных категорий в зависимости от целей боевого использования агентов и способов передачи информации:

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

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

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

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

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

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

Абвер, будучи одним из управлений ОКБ мог напрямую, выходить на главнокомандование войск и запрашивать всякого рода содействие и поддержку. Руководителями отделов Управления Аусланд/Абвер/ОКВ назначались опытные офицеры из кадров генерального штаба, каждые три года происходила ротация руководства. Проблема комплектации штата кадровыми офицерами чрезвычайно остро стояла перед всеми отделами Абвера. Так в отдел Абвер-1 набирали офицеров, имевших те или иные зарубежные связи, или офицеров, вернувшимся из долгосрочных заграничных командировок. Заполучение саперов и экспертов-практики по нацменьшинствам было задачей Абвер-2. Руководство Абвер-3 привлекало бывших сотрудников правоохранительных органов, криминалистов. В 1934 году в Вильгельмсхафене была открыта спецшкола Абвера по подготовке агентов для диверсионно-разведывательных операций в Западной Европе (Франция, Бельгия, Голландия).

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

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

"… Наибыстрейший способ передачи полученной развединформации — это радиосвязь. Радиостанции маскировались под радиоприемники, в арсенале Абвера существовало множество способов и стационарного размещения радиостанций, например, встроенная в стену рация с ключом, замаскированным под штепсельный контакт (розетка, вилка). Во время войны агенты-радисты, действовавшие в глубоком тылу противника, снабжались переносными рациями с батареями питания…"

Во время Второй мировой войны Рудольф Ф. Штаритц работал в чертежной Абвера, за все время ему довелось увидеть и поработать с чертежами и альбомами электрических схем радиоприемников Абвера. Несмотря на конфиденциальность выполняемой работы и риск быть пойманным, ему удалось сделать фотокопии некоторых схем соединений, некоторые схемы Штаритц просто воссоздал по памяти.

К 1985 году Рудольф Ф. Штаритц собрал достаточно материала для написания рукописи о радиосвязи службы Абвер. Но, несмотря на то, что его монументальная работа раскрывала до сих пор хранящийся в тайне кусок истории, он не смог найти хорошего издателя. В последующие годы отдельные части рукописи были опубликованы в немецком журнале Funk (1985, 1987, 1988 и 1989), а также в двух главах второго тома книги Фрица Тренкле «Die Deutschen Funknachrichtenanlagen bis 1945». Кроме того рукопись была передана частным лицам.

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


KW-приемник SX-28


KST-приемник

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

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

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

В филиале Верховного командования вооруженными силами Германии (Oberkommando der Wehrmacht — OKW) в Штансдорфе, основанном в 1936 году, над разработкой и производством первых коротковолновых устройств начали трудиться под руководством инженера Кайзера всего 4 механика. На тот момент во всем мире быстро увеличивалось число коротковолновой любительской радиотехники, благодаря радиолюбителям рынок развивался довольно активно. В начале войны многие из них были призваны или переведены в солдаты в соответствующие ведомства.

Перед войной служба Абвер ориентировалась на технологии английского рынка и приобрела (и в итоге скопировала) небольшие карманные приемники и передатчики, которые работали от батареек, в них использовались мини лампочки HIVAC (XY, XL и XSG в приемнике и две XP в двухтактной схеме передатчика). Удивительно, но эти миниатюрные на тот момент лампочки со вставным цоколем в Англии в антенно-фидерных устройствах не использовались.

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

Переносные коротковолновые радиостанции были лучшим и быстрейшим видом связи агентов с «Центром». Рации, которыми оснащались практически все агенты Управления Аусланд/Абвер, изготавливались и проходили стендовые испытания в техническом отделе А-1/и. После начала военных действий на европейском театре инженеры-конструкторы А-1/и после некоторых усовершенствований использовали и трофейные коротковолновые радиостанции. Радиограммы принимались на фиксированных частотах в заранее установленное время. В каждом военном округе была так называемая «радиостудия» — замаскированный приемо-передающий радиоузел. Лаборатория и центральный узел связи А-1/и находились в Штансдорфе под Берлином

.

Радиомастерская радиоцентра Гамбург-Вольдорф

В 1943 году конструкторское бюро и производство устройств АФУ были переведены из Штансдорфа в замок Нишвиц недалеко от Вюрцена.

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

Одним из довоенных устройств с наименьшим количеством схем — всего 3 лампы — был Mark VII / B «Paraset» британской секретной службы SIS. Это устройство АФУ с диапазоном частот 3-7,6 МГц; выходной мощностью до 5 Вт; с режимами работы — АМ и CW; питанием – 6В от батареи или выпрямителя; с антенной – проволокой, длиной не больше 20 м; габаритами 280х356х640 мм; массой – 1,2 кг.


Mark VII / B «Paraset»


Принципиальная схема Mark VII / B «Paraset»

Размер устройств АФУ в первую очередь зависел от используемых ламп. На рисунке ниже показаны радио лампы, используемые в немецких приемниках для работы от сети: CF7 для довоенных конструкций, металлические лампы (стеклянный баллон был заменен стальным) и так называемые желудевые лампы миниатюрных размеров 4695 (пентод) и 4671 (триод).


Лампы немецких передатчиков АФУ с питанием от сети

Что касается схемотехники, то немецкие устройства АФУ представляли собой так называемый двухконтурный приемник прямого действия с диапазоном частот (в зависимости от расстояния вещания) от 2 до 15 МГц.

S 90/40

S 90/40 — шпионский 40-ваттный коротковолновый радиопередатчик секретной службы Абвер, был разработан приблизительно в 1939 году в Штандорфе для использования во время Второй мировой войны. Начиная с 1942 года производство перенесли в Вурцен.

S-90/40 передатчик часто использовался в тандеме с приемником E-90 в шпионской радиостанции SE-90/40.


Радиостанция SE-90/40

Как автономный передатчик S-90/40 использовался обычно с ВЧ-приемником, таким как Siemens R-IV или Radione R3. Габариты устройства в темно-сером металлическом корпусе составляли 27,5 x 19,5 x 10,5 см, вес составлял 3128 грамм. Он запитывался от внешнего блока питания (PSU), который обеспечивал 12,3 В переменного тока (LT) для нитей накала и + 700 В постоянного тока для запитки анодов радиоламп.

Все компоненты управления и подключения S-90/40 располагались на передней панели, как показано на фото ниже. Вверху слева находился разъем под блок питания (БП). Справа вверху — измеритель тока в антенне, а левее находились разъемы для антенны. Антенна подключалась к крайнему правому разъему (T) и к одному из 4 разъемов слева. Внизу слева была размещена шкала частот (от 0 до 180 °) генератора переменной частоты (VFO).

Переключающее устройство, используемое для передачи знаков азбуки Морзе, подключалось
к гнездам в нижнем левом углу. После установки желаемой частоты, ручку настройки PA в правом нижнем углу следовало отрегулировать на максимальную выходную мощность, используя измеритель тока антенны как индикатор. Белый тумблер в центре — радио переключатель диапазонов. Базовая модель работала в диапазоне частот от 3,5 до 8,5 МГц, но были найдены и другие диапазоны частот, например, от 5,3 до 9,3 МГц.

Хотя S-90/40 иногда и использовался как автономный передатчик, он был разработан специально для шпионской радиостанции SE-90/40. Станция помещалась в прямоугольном чемодане, обтянутом черной кожей. Внутри чемодана — три отсека: один для блока питания (PSU) и вспомогательных устройств, второй для приемника E-90, третий для передатчика S-90/40.


Радиостанция SE-90/40

Ниже на изображении — принципиальная схема S-90/40. Она представляет собой так называемый «тропический» вариант S-90/40 и основана на принципиальной схеме военного времени, опубликованной Рудольфом Старицем.

SE 99/10

Настоящим произведением искусства 1942 года под названием «миниатюрное коротковолновое устройство, работающее от сети» по праву можно считать SE 99/10. Устройство размером примерно с коробку для сигар было первым немецким коротковолновым аппаратом, к которому можно было подключить маленький ключ Морзе. В зависимости от рабочего расстояния он поставлялся в диапазоне приема и передачи от 2,5 до 5,5 МГц, от 3,5 до 7,5 МГц или от 4 до 9 МГц.


SE 99/10

SE 109/3

SE 109/3 был шпионским передатчиком / приемником, разработанным во время Второй мировой войны в 1942 году в Вурцене для Службы безопасности Германии Абвер. Радиостанция была запущена в производство в 1943 году и использовалось Абвером, а также его преемниками. После войны, с устройством работало разведывательное агентство Gehlen (OG) и даже BND.

Жестяной корпус радиоустройства (передатчик и приемник) визуально напоминал коробку из-под печенья, потому его часто называли Кексдозе. Устройство запитывалось от внешней аккумуляторной батареи 1,2В (LT) и 90В и 270В (HT), но в комплекте шел еще дополнительный блок питания, который подключался с тыльной стороны. 3Вт передатчик с кварцевой стабилизацией частоты мог иметь до двух фиксированных каналов в дополнение к одному настраиваемому.

Приемник свободно регулировался в диапазоне частот 3,2–6,5 МГц, передатчик — 3,3–7,5 МГц. Передатчик подходил только для CW волн и использовался для отправки сообщений азбукой Морзе при помощи встроенного съемного ключа Морзе.

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

Габариты SE 109/3 составляли 20 x 14 x 6 см, вес — всего 1,7 кг. Элементы управления и соединения размещались со всех сторон радиостанции, кроме нижней части. Корпус представлял собой прямоугольную жестяную коробку с округленными углами, нижняя и верхняя панели легко снимались. Слева 2/3 занимал приемник, а оставшуюся 1/3 — передатчик. На верхней панели размещались три больших отверстия, через которые были видны черные лампы DF11 приемника. Отверстия выполняли функцию охлаждения.

Антенна и противовес подключались через разъемы на верхней панели. Для подключения динамика на 4000 Ом или пары наушников 2 x 2000 Ом служили разъемы слева на передней панели.

Все органы управления приемником были расположены на левой боковой панели. Переключатель ON / OFF использовался для включения напряжения для нитей накала. Чтобы отрегулировать частоту приема от 3,2 до 6,5 МГц нужно было покрутить поворотный переключатель, расположенный слева ближе к задней стенке приемника. Текущая настройка отображалась на линейной индексной шкале на верхней панели.

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

SE-109/3 запитывался от внешней батареи или от внешнего блока питания (PSU), который подключался к 4-контактному разъему на задней панели прибора. Радиоприемнику необходимо было три напряжения: 1,2 В, 90 В и 270 В.

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

SE-109/3 обычно хранился в небольшом фанерном ящике, покрытом черной искусственной кожей. Кейс закрывался при помощи двух кожаных ремней. Аналогичный чемоданчик шел и для аккумуляторного блока, в нем размещалась батарея 1,2 В для нитей и три анодные батареи 90 В.

Из-за конструкции корпуса добраться до «внутренностей» SE-109/3 было легко, верхняя и нижняя панели устройства снимались элементарно, как крышка от коробки для печенья. На изображении ниже показан интерьер SE-109/3, если смотреть сверху. Примерно 2/3 пространства занимал ресивер (слева). Хорошо видны три большие черные лампы DF11 передатчика.

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

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

SE 100/11

Самым миниатюрным коротковолновым устройством для работы от сети, которое серийно производилось во время Второй мировой войны, была радиостанция SE 100/11. SE 100/11 состояла из трех подключаемых и очень плоских частей: двухконтурного приемника (лампы EF11, EF12 и EDD11), блока питания (EZ11, DGL 150/10) и передатчика, частоту которого определял внешний кварцевый резонатор с лампой UBL21.


SE 100/11


SE 100/11, слева направо: приемник, БП, передатчик

Криптоустройства Абвера

Для засекречивания сообщений использовалось множество ручных и машинных шифров. Для обмена данными между ОКВ и зарубежными подразделениями, например в Аргентине, Абвером использовалась Enigma G31, поэтому ее еще называют Abwehr Enigma. Ближе к концу войны Абвером была разработана шифровальная машина SG-41, в итоге получившая прозвище «Мельница Гитлера» (Hitlermuhle), она должна была заменить известную Enigma.

Enigma G31

Эту криптомашину иногда называют Abwehr Enigma, поскольку она использовалась немецкой секретной службой, Абвер. Однако следует отметить, что это была не единственная шифровальная машина, используемая секретной службой. Enigma G31 широко использовалась в гражданских и военных целях в таких странах как Венгрия и Нидерланды. Машина приглянулась в военное время и Sicherheitsdienst (SD), службе безопасности Германии.

Что немаловажно Абвер использовал иную проводку, чем другие заказчики этой криптомашины. Для сохранения схем проводки в секрете, службой были заказаны у производителя заготовки роторов (т.е. роторы без проводов). Кроме того, отделы Абвера использовали роторы с разной проводкой. По факту ее продолжали называть Zählwerk Enigma, так как G31 была разработана на основе Enigma А28.


Enigma А28

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


Enigma G31

Удачными моделями Enigma G были G-312 (использовалась Абвером), и G-260 (SD). Уцелевшая с 40-х годов прошлого столетия G-312 — редкий экспонат в музее Блетчли-Парк. В 2001 году была совершена кража критомашины просто среди бела дня, но ее удалось вернуть.

Дефолтное подключение G31 В приведенной ниже таблице показано подключение Enigma G по умолчанию, которое было идентично подключению коммерческой Enigma D. Единственное отличие — количество выемок на каждом роторе. Электропроводка и расположение выемок идентичны Zählwerk Enigma A28.

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

В марте 1945 года, незадолго до окончания Второй мировой войны, аргентинская полиция арестовала немецкого шпиона Иоганна Зигфрида Беккера. У него была изъята модель Enigma G31 с серийным номером G-260. Через два месяца криптоустройство было передано американцам. Хотя Беккер и работал на немецкую секретную службу Абвер, G-260, скорее всего, использовалась Службой безопасности Германии (Sicherheidsdienst SD). У СБ Германии была своя собственная сеть в Аргентине, которую союзники называли Красной. Их экземпляры Enigma G31 были подключены иначе, чем машины, которые были в эксплуатации у Абвера в Аргентине.

С технического описания Zählwerk Enigma следует, что машина явно доработка Enigma D с некоторыми дополнительными функциями и улучшениями. Наиболее разительным отличием от других моделей Enigma является способ перемещения роторов. В более ранней Enigma D (а также в более поздней Enigma I, которая использовалась немецкой армией) роторы перемещались с помощью собачек, трещоток и зазубрин. В результате роторно-шаговый механизм этих машин двигался только вперед.

Однако в Zählwerk Enigma роторы приводились в движение благодаря зубчатой коробке передач. Количество выемок на каждом роторе было разное. Еще одно отличие от Enigma D — отражатель, который можно было не только установить в любое из 26 положений, но и перемещать во время шифрования. Три кодирующих ротора крепились на шпинделе, как и в других моделях Enigma, а вот отражатель перестал быть фиксированным.


Обычные роторы Enigma (слева) и роторы Zählwerk Enigma (справа)

Роторы стандартной Zählwerk были того же диаметра, что и роторы предыдущих моделей машины Enigma (например Enigma D). Однако в более поздней модели G31 диаметр роторов меньше, как показано на рисунке ниже.


Роторы Zählwerk Enigma модели A28 (слева) и Enigma модели G31 (справа)

Большинство устройств поставлялось всего с 3 роторами шифрования, их можно было установить на шпиндель в 6 различных порядках (3 x 2 x 1). Эти колеса (I, II и III) шли с 17, 15 и 11 выемками соответственно. Известно, что некоторые криптомамашины Enigma имели в своем распоряжении больше трех роторов шифрования. В венгерской армии, например, были машины Enigma G31 с пятью такими роторами.

Мельница Гитлера или SG-41 представляла собой механическую шифровальную машину с штифтом, была разработана во время Второй мировой войны. Фриц Менцер разработал достойного кандидата на замену Enigma-G. Устройство было изготовлено компанией Wanderer Werke в Зигмар-Шёнау 12 октября 1944 года. Поступил заказ на 11 000 единиц. Свое прозвище Hitlermühle (Мельница Гитлера), скорее всего, устройство получило из-за наличия большой рукоятки с правой стороны.


SG-41, в итоге получившая прозвище «Мельница Гитлера» (Hitlermuhle)

В отличие от Enigma, SG-41 не относилась к роторной машине, а являлась улучшенной версией C-машин на цевочных дисках, разработанных Борисом Хагелиным в Швеции. Подобные криптоустройства Хагелин начал создавать еще перед войной (C-36 и C-38), они активно использовались в американской армии (M-209 и BC-38).

SG-41- усовершенствованная версия BC-38 и M-209, к улучшениям можно отнести нерегулярное перемещение роторов, смещение роторов в обоих направлениях, что в целом затрудняло взлом криптоустройства. Что касается внешнего вида, то SG-41 сильно отличалась от C-машин Hagelin. Корпус — выше, внизу имелось большое отделение для хранения бумаги.

Устройство приводилось в движение при помощи рукоятки справа. На передней панели слева находился счетчик символов, его можно было сбросить при желании (Сounter reset на фото выше). Вверху располагались шесть роторов, которые можно было разблокировать при помощи рычага справа от них (wheel lever). После разблокировки можно было установить роторы в начальное положение.

SG-41 впервые была обнаружена взломщиками кодов в Блетчли-парке 12 октября 1944 года. По словам Мэвис Бэти, все что они знали, что у машины было шесть шифровальных роторов, которые перемещались нерегулярно, иногда даже назад. Хотя специалистам позже и удалось расшифровать несколько сообщений, во время войны машина оставалась нерушимой загадкой, а в послевоенном отчете США ее называли «удивительной».

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

Разведка в том виде, в каком она предстала в начале войны осенью 1939 г., была в основном творением Канариса. Из «мелкой лавочки» она превратилась в большую и весьма мощную организацию. Канарис гордился своей разведкой.

Но успех функционирования внешних связей Абвера все отчетливее вырисовывал перед адмиралом и его офицерами истинную обстановку с близящейся катастрофой. Канарис продолжал борьбу с РСХА, которое до 1944 года так и не смогло представить Гитлеру никаких компрометирующих материалов разведывательного характера на Абвер.

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

В феврале 1944 вышел декрет о расформировании Абвера. Этим декретом Абвер делился на части, отходившие к разным ведомствам, — в основном в состав Главного управления имперской безопасности (РСХА). Начальнику ОКВ и рейхсфюреру СС было поручено перевести Абвер в тайную службу РСХА, что по указу Гитлера создало бы единую разведывательную систему. Адмирал Канарис был приговорен к смертной казни, обвинен в участие в попытке государственного переворота, и казнен 9 апреля 1945 года в тюрьме Флоссенбурга.

Немного рекламы

Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?

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