Today I want to tell my thoughts about classification in managed services, especially on the example of databases.

In what sense do we usually understand the word "managed" in descriptions and news of cloud providers like AWS, GCP, Azure? It's often something like: "You don't need to care about scaling, patching versions, making and restoring backups and so on. Just pay and use the selected databases as you want".

But I think, it's not completely true and sometimes it is partially a marketing description. In my opinion, true classification of managed databases consists of the following three types:

1) Not-managed (on-premise). This is the old classic approach - you install a database on your local server or virtual machine. Everything - selecting a server, scaling, calculating load, making and restoring backups, solving problems with performance and so on is in your hands.

2) Partially managed. Using databases from this category saves you from some problems like making backups, patching the database and other. But some problems are still on your side: selecting the type of node instance before start a database, type of storage, IOPS, increasing numbers of replicas (horizontal scaling) and so on. I put AWS RDS, Aurora, ElastiCache with custom setup into this category instead of calling it "fully-managed".

3) Fully managed. Using fully managed databases you really don't care of "how many nodes do I need?", "how powerful my nodes must be?", "how can I make a backup?", "how many vCPU and vRAM do I need?". You can really put in your database 10 MB of data and after one minute - one terabyte. Or read today 10 GB/s, tomorrow - only 10 MB/s. You don't need to select t2.micro or x2.large or other instance type for your nodes. Some examples of the fully managed databases: AWS DynamoDB, AWS ElastiCache serverless, MongoDB serverless, CockroachDB serverless, possibly Google BigTable.

So, I think using the above classification will make it easier to select a database and configuration that best satisfies your needs.

I've been working with Go for almost 4 years now. And all this period i communicate with other Go developers in profile articles, Telegram chats and other groups. One of the most popular subject in post-soviet developers communities is best architecture. Two most popular approaches are Domain Driven Design (very unuseful approach in my opinion, but it's subject for my future posts) and Martin's Clean Architecture.

In some periods of my career i was working with different architectures (includins DDD and no-architecture chaotic approach) on Go. So now i am working with my own version of Clean Architecture and i decided to demonstrate it on some example repo. Here it is: https://github.com/nightlord189/ca-url-shortener.

In this version i use only 3 circles of layers and it's enough for most web projects. Also in many real project on start i can set solid dependency connection (not by interface) and use single model both for database and http (using Go struct tags). They are deviations from the Clean Architecture concept (as Martin declared it in his book) but i think that you must adopt any architecture to your project.

Any software architecture approach is like Scrum for project management methodology. There is no "Ideal Scrum" like Holy Bible. You are creating new different Scrum implementation for each project team. Also you should create your own implementation of architecture approach for each new project which you are developing too.

If you want to create your own blog - you need to choouse from some cool existing solutions.

I provided short list of these solutions when i was choosing which platform will be more convenient for me.

Hugo

Hugo is a generator of static site. It's written on Go (respect from me as Golang-developer). You should create your own git repository, install Hugo, choose visual theme (https://themes.gohugo.io). Next you can create .md Markdown files, write content in it and run hugo command - it will create static html/css files. These files next you can host by Github pages, Vercel, nginx or other ways. 2nd version of my blog was made with Hugo and it's cool tool.

Gatsby

Gatsby is another static site generator written on JS. It uses React and SSR under the hood. I have not tried it, but read many good reviews from users.

Wordpress

Wordpress is widely used CMS (content management system) and it has many features based on hundreds of plugins. You can create full-functional blog, forum, landing page, shop or other types of sites. But it also has some security issues and almost all cool plugins require paid version.

Ghost

Ghost is blog platform. It is written on JavaScript and requires database (MySQL) to use. It also offers many features besides blog posts: free and paid membership, email letters, custom pages, changing visual themes. It has very convenient editor for blog posts. As disadvantage i can point that Ghost works only with Stripe for paid memberships and Stripe isn't available for some countries like Kazakhstan.

Popular social network

Another way - create account in popular social network like Facebook, LiveJournal, Linkedin or forum like vas3k.club. With this way you can get first readers and subscribers very fast because social network already has many users. But as disadvantage - your content is not realy "yours". Social network can delete your account or post at every moment based on strange rules or moderator's personal mood. You cannot export your content to one file for backup. Forums also doesn't allow you to create anything that you want. For example my favorite forum vas3k.club clearly took a course on simpler everyday stuff rather than on technical topics. In some cases I even got messages from moderators: "this topic doesn't match the club's course, go the chat".

What tool I chose?

My very first version of blog was built on Wordpress. But I couldn't create a design that suited me. Then i recreated new version on Hugo with Github Actions. Although i am a developer and can work with Git it was very inconvenient for me - every time when i want to create new post or edit existing - go to IDE, edit markdown, git commit & git push... It's so tired. I wanted only to login as admin, edit some text in something like Word or Google Docs and press Publish. Finally current version of my blog/personal site is created on Ghost and now it suits my needs.
So in a dispute "host your posts on personal website / host it in a social network" i choose both. All my posts (maybe except something like "Congrat me, i got new certificate") will be listed on my personal site, but main of their will be posted on Linkedin as my main social network for career now.

Some Notes on Fixing Ghost After Setup.

I use CapRover to host this blog and my other projects. I chose Ghost for this blog, and sourced the image from Caprover one-click-apps repo which uses Docker image from Bitnami.

After install almost all worked good, but there were two issues:

1. Sometimes i received 500 error upon accessing the index page. I suspected that the problem might be related to database connection timeouts.
2. I couldn't view logs in Docker stdout when accessing them via docker logs or DockLogKeeper.

After some online research, I found the following solution:

1. Move to the volume, attached to your self-hosted Ghost instance (/var/lib/docker/volumes/captain--blog-data/).
2. Cd _data
3. Edit config.production.json, adding

"pool": {
    "min":0
}

to the database section of config

4. Add "stdout" option to the logging->transport section:

"logging": {
    "transports": [
      "file",
      "stdout"
    ]
  }

5. Restart your Ghost container.

Your config.production.json should now look like this:

{
  "database": {
    "client": "mysql",
    "connection": {
      "host": "srv-captain--blog-db",
      "port": 3306,
      "database": "ghost",
      "user": "ghost",
      "password": "your_password",
      "ssl": false
    },
    "pool": {
        "min":0
    }
  },
  "url": "https://example.com",
  "server": {
    "port": 2368,
    "host": "0.0.0.0"
  },
  "mail": {
    "transport": "SMTP",
    "from": "from@example.com",
    "options": {
      "host": "smtp.gmail.com",
      "port": 587,
      "secureConnection": false,
      "auth": {
        "user": "from@example.com",
        "pass": ""
      }
    }
  },
  "logging": {
    "transports": [
      "file",
      "stdout"
    ]
  },
  "process": "local",
  "paths": {
    "contentPath": "/opt/bitnami/ghost/content"
  }
}

Ideally, these settings should work as environment variables in Bitnami containers, or perhaps be configurable via the admin panel in future versions. For now, though, we have to manually edit the config file.

Related links:

• https://github.com/TryGhost/Ghost/issues/9739
• https://www.soo.sg/resolving-ghost-and-caprover-error-500-econnreset/

Запустил первый более-менее полезный open-source проект - DockLogKeeper - просмотрщик логов Docker-контейнеров (https://github.com/nightlord189/docklogkeeper). Пока альфа-версия, так что возможно все)

Делал для себя, очень удобная штука, когда хочется в веб-интерфейсе видеть сразу логи всех контейнеров с возможностью поиска и при этом не хочется поднимать и настраивать Grafana/ELK/Graylog, конфигурировать logging-drivers и прочее.

Хранит записи в локальной SQLite-базе, так что не страдает от остановки/удаления/перезапуска контейнеров. Запускается одной командой.

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

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

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

На чем зиждется эта позиция Kaspi на рынке? На мой взгляд, на нескольких преимуществах:
1) Первое и основное - переводы. Именно с ними Kaspi когда-то совершил революцию и сильно цифровизировал наше общество. Если ты хочешь кому-то быстро перевести деньги за услугу или товар - welcome to переводы.
2) Маркет. Сейчас, мне кажется, многие интернет-магазины вообще ушли только в kaspi, а у других значительная часть товаров заказывается через Kaspi Маркет.
3) QR, госуслуги, счета и т.д.

Хотя в 3 пункте Kaspi постоянно расширяют функционал, делают новые сервисы и покупают существующие (Santufei -> Kaspi Travel), тем не менее, такое безальтернативное положение на рынке им обеспечивают именно переводы и Маркет.
И если к Маркету у меня вопросов нет, то насчет переводов - я думаю, мы уже достаточно созрели в техническом и организационном плане, чтобы сделать переводы между физлицами не преимуществом отдельного банка, а всеобщим национальным достоянием.
Как это может выглядеть? Я думаю, нам стоит посмотреть на опыт северного соседа с СБП (Система Быстрых Переводов) и QR.

Как я это представляю? В Казахстане создается оператор СБП - шина переводов, к которой на законодательном уровне мы обязываем подключиться все банки. Таким образом, чтобы любой клиент любого казахстанского банка мог перевести деньги другому клиенту, зная его номер телефона. Чтобы этот перевод шел так же быстро и просто, в 2 клика, как сейчас у Kaspi, но через нашу СБП. И неважно, какие именно банки у адресата и отправителя. Аналогично и с QR - QR должен быть подключен к единой национальной шине, а не быть единоличным сервисом какого-либо банка.

Что это даст Казахстану? Сейчас, на взгляд обычного юзера, другие банки хоть и пытаются конкурировать с Kaspi на рынке физлиц, но реального шанса у них нет. Т.е. какими бы преданными пользователями другого банка Иван Петров или Нурлан Исаев не были - без Kaspi им не обойтись. Введение нашего аналога СБП и СБП QR снова поставит все казахстанские банки в равные условия и позволит им конкурировать на равных за внимание клиентов, вводя новые интересные цифровые продукты и имея реальный (а не призрачный) шанс перетянуть к себе часть клиентов. Это позволит кому-то в банковской сфере снова совершить некий технологический скачок в финтехе, как это сделал ранее Kaspi с переводами. Это плюс и для Kaspi, так как, на мой взгляд, они тоже уже достаточно привыкли к монополии и куда меньше борятся за внимание клиентов, понимая, что они никуда не уйдут.

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

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

Основные преимущества облачных провайдеров сейчас фактически такие:

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

2) Резервирование данных и инфраструктуры. В частности, в AWS много чего резервируется автоматически без дополнительных усилий. Например, при использовании каких-нибудь DynamoDB/BigTable данные будут многократно дублироваться на случай отказа в разных ЦОДах. Также легко можно настроить дублирование для разных регионов планеты, если хочется оптимизировать пользовательский опыт. При самостоятельном же построении инфраструктуры на дедиках - придется самостоятельно настраивать резервирование данных и серверов и следить за этим (см. 3 пункт).

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

При этом, хотя многие провайдеры декларируют еще и преимущество экономии, оно обычно актуально только для крупных компаний с обширной инфраструктурой, либо для проектов с очень нерегулярной нагрузкой (например, продажа доступа к файлам с контентом, или распродажа/фестиваль - тут дешевле положить три файла в s3 и захостить serverless-бэкенд, чем поднимать vds/vps со всей обвязкой и держать ее 24/7).

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

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

1) Экономия. Более того, это экономия со звездочкой. Думаю, все читали истории о стартаперах/инди-разработчиках, которым после месяца оплаты за $120 внезапно прилетал счет на $20 000 из-за неправильно настроенных или отсутствующих лимитах и пошедшему большому трафику (внимание пользователей/ddos/что-то еще). С кейсом своей инфраструктуры это невозможно, т.к. мы всегда платим фиксированную сумму за месяц, не больше и не меньше (есть нюансы с трафиком, но все зависит от контекста).

2) Гибкость. В любой момент всю инфраструктуру можно будет относительно безболезненно перенести к другому провайдеру. В отличие от кейса, когда мы используем максимальное количество провайдер-специфичных сервисов (DynamoDB, BigTable, Lambda, Fargate) - перенос к другому провайдеру будет или невозможен, или потребует огромное количество ресурсов и времени на переписывание кода.

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

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

В итоге получился максимально простой JSON-beautifier - https://jsonbeautifier.tinygreencat.dev, тем не менее, с нужной мне фишкой, которой я не видел у других - одновременно с обработкой он может еще и делать unescape (замена /" на ") символов.

Т.к. я часто смотрю логи, в которых json как раз так и выводится, мне постоянно приходится автозаменой делать unescape в блокноте и уже потом "украшать" json в postman/на других сервисах. С использованием своего же проекта, чуть-чуть ускорю этот процесс - будет один шаг вместо двух.

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

Хотел бы высказать тут пару мыслей о кредитной сфере.

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

Предварительное одобрение

Я регулярно сталкиваюсь в своей жизни с таким термином как "предварительное одобрение". Например, вы клиент банка А. И однажды вам приходит смс (или звонит менеджер) от банка с примерно таким текстом:

Уважаемый {CLIENT_NAME}! Вам одобрен кредит на сумму {X денег} на {количество месяцев} период с ежемесячным платежом {Y денег}. Чтобы получить кредит - позвоните в банк/подойдите в отделение/зайдите в приложение.  

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

Таким образом, может получиться, что вам сперва сделали предложение по кредиту, а при настоящем одобрении вам тупо отказали. Или изменили условия (срок, сумма, ставка).
Периодически, например, я вижу комментарии в ветке обсуждения автокредитов kolesa.kz (при подаче заявки через приложение сперва выносится предварительное одобрение, а настоящий процесс одобрения начинается только когда вы подъедете на СТО и обратитесь к менеджеру) - человек подал заявку на понравившийся автомобиль, получил одобрение в приложении, потом поехал на СТО в другой город или область, проделал неблизкий путь, выдернул продавца - и в итоге получил отказ.  
Опять же у меня есть кейсы, когда мне лично звонили с банков и предлагали неплохие условия, а при непосредственной подаче заявки отказывали вообще.

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

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

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

Кто-то может сказать: "а в случае автокредита как банк оценит залог? А вдруг там на самом деле убитая машина или тотал, а это все с целью мошенничества?".
Мое мнение - залог можно оценивать, но только для коррекции суммы в сторону уменьшения.
Т.е. если вдруг одобряли 15 млн, а выяснилось, что авто не на ходу - можно снизить, например, до 8 млн. Но на сам факт одобрения это не должно влиять никак.

Прозрачность принятия решения

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

Банк вам никогда не сообщит истинную причину. Обычно сотрудники ее и сами не знают.
Максимум могут быть какие-то рекомендации вроде "погасите штрафы", "укажите других контактных лиц" и так далее, которые основаны исключительно на личном опыте самого сотрудника.  
Итого, отношение к клиенту в духе "Мы ничего тебе не одобряем. Почему? Просто мы так решили, вот почему. Приходи потом через месяц, попробуй еще подолбись в нашу систему." или "Мы одобрили тебе 0.5X вместо Х. Почему? Потому что мы так решили, вот почему".

Моя идея здесь заключается опять же в обязательном регулировании этого этапа со стороны законодательства и финансового регулятора.
Сейчас большинство решений принимают автоматизированные системы и модели, настроенные специалистами внутри банка. По каким именно весам и критериям они это делают - посторонний человек не знает.
Идея в том, чтобы при отказе или изменении условий клиенту кредитор был обязан вывести либо достаточно точную причину отказа, либо критерии, по которым его модель принимает решение.
Например, если мне отказали из-за маленького дохода - сообщение должно быть в духе "для запрошенной суммы необходим ежемесячный доход в 300 000  тенге, тогда как у вас только 285 000".
И при устранении или изменении этой причины (если это вообще возможно) при прочих равных я должен получить одобрение.

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

Еще более "безумная" идея - разработать вообще единую модель, которую (возможно, с некоторыми поправочными коэффициентами) будут обязаны использовать вообще все финансовые учреждения при одобрении.
Которая должна регулярно пересматриваться и обновляться специалистами Нацбанка и быть единой для всех. А использующиеся сейчас кастомные модели для каждого банка и МФО выпилить вообще.  
Т.е. при обращении клиента А банк делает запрос с его ИИН и другими параметрами к серверам Нацбанка, получает ответ, применяет свои повышающие или понижающие коэффициенты и отдает ответ клиенту.
Это открывает еще и возможности по прямому регулированию закредитованности населения на государственном уровне.

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

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

Пример плохого вопроса, не соответствующего этому правилу (предположим, речь идет о курсе по основам HTTP-протокола):

1. Какое назначение у статус-кода 425:
A. URI Too Long  
B. Unprocessable Entity  
C. Too Early

(Правильный ответ - C) Что здесь плохого? То, что ни один студент не должен тратить свое время на заучивания назначений всех кодов HTTP. Достаточно запомнить их группы и 5-10 самых общеупотребительных.

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

1. Для чего используются статус-коды группы 3xx?
A. Ошибка клиента
B. Ошибка сервера
C. Перенаправление

Правило 2: если соблюдается правило 1, то в тесте с вариантами ответа правильный вариант должен быть абсолютно очевиден (не должно быть ощущения "спорный момент").

2. Чем является JSON?
A. Текстовый формат обмена данных  
B. Формат представления данных при передаче по HTTP  
C. Формат конфигурационных файлов  

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

Правильный вариант этого вопроса выглядел бы так:

2. Чем является JSON?  
A. Текстовый формат обмена данных  
B. Язык программирования  
C. Регистр процессора  

Еще один пример плохого вопроса:

3. Кто является автором цитаты "FORTRAN — это не цветок, а сорняк: он вынослив, иногда расцветает и произрастает в каждом компьютере" ?
A. Alan J. Perlis.  
B. Thomas C. Gale  
C. Alan Kay  

Что тут плохого? А то, что ни один студент и ни один нормальный здравомыслящий человек, ценящий свое время, не обязан помнить абсолютно ничьи точные слова и цитаты, как бы известны они не были. Правила, факты - да. Но не цитаты и не 100% точные формулировки.

Правило 3: если предоставленный ответ отвечает на открытый вопрос, но не совпадает с образцом - это корректный ответ. При сомнениях можно запросить уточнения, но не следует ожидать даже 50% точного воспроизведения образцового ответа или определения из учебника.

Вспоминаю свой устный экзамен по физике на 2 курсе, когда в заключительном вопросе меня попросили сформулировать определение какого-то физического понятия. Я это сделал, а затем повторил еще раз, сформулировал другими понятиями, показав на примере, как это можно вывести от базовых аксиом. Мои определения были достаточно корректными, однако в голове экзаменатора было другое определение и именно его он ждал. Возвращаясь к нашему примеру с JSON, преподаватель ждал ответ "Текстовый формат обмена данных", а получил: "Формат представления данных в формате ключ-значение".
Является ли это достаточно корректным ответом? Абсолютно, особенно если уточнить.

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

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

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

Приведу тут достоинства и недостатки двухфакторной аутентификации.

Достоинства

• Безопасность

Недостатки

• Нужно иметь под рукой смартфон или аутентификатор
• Лишние телодвижения при аутентификации

Мое непопулярное мнение состоит в том, что мне в принципе не нужна двухфакторная аутентификация нигде.
Поясню. Есть по сути два диаметрально противоположных варианта - либо мы используем 2FA, либо нет. Если мы ее используем - нас сложнее взломать. Однако если мы ее не используем - то мы можем проснуться где-нибудь в избушке лесника в Сибири, зайти в интернет с ноутбука с Windows XP на последнем уровне заряда батареи и без проблем зайти в личный кабинет, помня только адрес сайта, логин и пароль.

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

Небольшой список примеров в моей жизни, где мне мешает 2FA:

• Однажды когда мне в другой стране понадобилось срочно зайти в интернет-банк - я не смог этого сделать из-за обязательной двухфакторной аутентификации на входе (смски в роуминге не приходили)
• Зашел в браузере в давно не используемый Google-аккаунт, созданный для родственника. На входе сразу же запрос на привязку номера сотового. Я привязал номер родственника, и буквально через 20 минут при повторном входе с того же компьютера получаю сообщение о том, что я захожу из подозрительного места и будьте добры ввести смс-код. До свидания, аккаунт, приятно было повидаться. Прощай, настройка)
• Постоянные требования [Github](https://github.com) при входе ввести код из email меня просто нереально подбешивают. Я согласен, чтобы мои публичные репозитории украли и перепродали в Даркнет или еще куда, только уберите эти проверки!
• Работа в Itunes Connect. Раньше для настройки приложения, которое я поддерживаю, я спокойно заходил с аккаунта владельца (с его согласия) и не было абсолютно никаких проблем. Теперь же для аккаунтов разработчиков Apple требует принудительно ставить 2FA, после чего у нас начинается веселый цирк с конями: "Напишите пароль, который пришел на айфон, это я захожу".
  
  В будущем для своих пользователей на любом сайте/сервисе, где я буду разработчиком, я всегда буду оставлять возможность отключить двухфакторную аутентификацию (в настройках личного кабинета, например), если у меня будет такая возможность.