Раньше у iOS была Cidya – некий аналог AppStore для взломанных девайсов с джейбрейком. Сидия существует до сих пор, но все это уже мало актуально. Я как-то читал пост одного из разработчиков Сидии, правда пост был посвещен тому, как правильно общаться с правоохранительными органами, гг. Сейчас есть джейл даже для iOS 14, правда, для каких-то уже богом забытых девайсов, поэтому популярность этого метода и сошла на нет. Короче говоря, в этом сторе можно было качать приложения бесплатно, обходить верификацию донатов в играх и приложениях, где не было серверной проверки (не уверен, что тогда вообще эта фича была у Эппла), и все такое. Это время прошло.
Еще давно я наткнулся на похожий аналог, только сделанный более тактичнее – с помощью сервиса тестирования приложений для разработчиков TestFlight. Инвайт в эту штуку пришел мне спустя почти год, как я оставил заявку :)

Это официальный инструмент с помощью которого можно тестировать приложения до их попадания в AppStore, не устанавливая билд напрямую с Xcode. Эппл активно развивает эту тему, поэтому сейчас порой достаточно перейти по ссылке и сразу скачать тестовый билд себе на телефон. Аналог, о котором я веду речь – Airport.community, сообщество разработчиков под iOS. Оставляете заявку, получаете инвайт в основное приложение и попадаете в сам магазин.

Если охарактеризовать вкратце, то Airport – это Behance для разработчиков. Идея в том, чтобы у разработчиков появилось место, где они бы могли опробовать свои идеи, получить какой-то первичный фидбек и все такое. Я же рассчитывал получить там чего-то такое, чего нет в AppStore. Какие-нибудь удаленные приложения и все такое. А оказалось, что это просто еще один магазин. С кучей приложений, которые не нужны.

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

Однако, я обнаружил приложение, которое в данный момент уже опубликовано – Bolt. И там есть подписки. Это оказался тот самый бонус, который можно получить из этого инструмента. В TestFlight версии тоже есть подписки. Особенность TestFlight в том, что все покупки там фейковые и за них не нужно ничего платить. Это и понятно – иначе девелоперы разорились бы на тестировании своих покупок. Я смог подписаться на это приложение бесплатно и получить тот же самый функционал, за который в магазине Эппл возьмет денег. Странное решение от человека, который делает это приложение, хотя, с другой стороны, количество людей, которые вообще знают про Airport трагически мало – я спрашивал про него у всех своих знакомых iOS разработчиков и все они слышали про это в первый раз.

Раньше Эппл были против публичного распространения приложений через TestFlight. Я помню прецеденты, где с помощью Энтерпрайз аккаунтов распространяли приложения публично, просто выкладывая линки где-то в вебе и таким образом обходили ревью. Эппл банили такие организации и удаляла все их приложения. Не думаю, что сейчас что-то изменилось, поэтому такой долгий процесс получения инвайта в эту штуку вероятно связан именно с этими рисками. И несмотря на то, что Airport по сути публично распространяет приложения в обход ревью Эппла и никто по факту не знает, что именно таят в себе эти приложения и какие данные они могут собирать, эта тема все еще жива. У них есть Twitter, где они постят свои обновления, рассказывают какие новые приложения появились и все такое.

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

На рынке есть много решений по автоматизированной модерации контента – будь то гугл или прочие ноунейм стартапы. Но все это будет интересно разве что каким большим проектам. То есть, мне сложно представить, чтобы какой-нибудь начинающий стартап или просто проект, сидящей на небольшой прибыли, готов был бы раскидываться деньгами в сторону бесконечных сервисов гугла или всяких сомнительных чуваков, которые меряются своим AI между собой. Но внезапно под Гуглом появился небольшой сервис, который бесплатно дает API по модерации комментов и при этом нормально работает. Встречаем странное название – Persceptive. Этот сервис вошел в список сервисов Гугла совсем недавно, когда я его обнаружил он был еще отдельно живущий. Что он делает я покажу в одном скрине:

Подытожим:

• бесплатно;
• работает.

Digital Ocean – это такой облачный хостинг, который любят за недорогие цены на небольшие виртуалки для дев целей и прикольные мануалы. Они очень пытаются быть модными и крутыми, делая всякие маркетплейсы с готовыми сборками разных утилит, предлагая функциональные кластера Кубера, вводя в линейку memory-optimized сервера, позволяя создавать отдельные приватные сети для конкретных машин, создвать теги и называя свои сервера Дроплетами. Под словом пытаются я хочу сказать, что сами они себя ставят в один ряд с AWS и GCM. Но нельзя просто так взять и стать топовым облачным провайдером. На собственном примере расскажу, почему меня в этом не убедили.

О чем это я

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

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

1 и 2 случаи

БД начинает много писать и читать. Быстро упростить нагрузку и не накосячить не получится, нужно немного пожить в этом состоянии – иопсы под потолок, цпу скачет туда-сюда каждый вечер, слегка рисуя iowait. Сервер ресайзить нет смысла, вся нагрузка упирается в диск. Хотелось бы отключить логи и снизить нагрузку на диск, но логи были нужны. Решение было очевидное – подключить еще один диск, писать логи в него. Так и сделали – хорошо живем, вроде чуть попроще стало. Как-то раз девелопер решает зафигачить большой-большой запрос по логам, который он делал и раньше. Бамс основной диск ложится. “Но ведь это два разных диска!” – говорили они мне. Оказывается, не особо. Я сейчас уже этот момент на графиках в истории на найду, но там было видно, как подскочили показатели сразу двух дисков одновременно и вернулись, как только запрос отменили. Ну, штош, решили пока не делать таких запросов.
Прошло пару дней и внезапно диски упали вообще. CPU показал 99% iowait, записи и чтения нет, сервер сам доступен. Опытным путем выяснили, что проблема с диском логов – база не может записать лог и валится. Сервер уходит в ребут – нет эффекта, через пару минут тоже самое. Выключили сервер через дашборд DO и включили. Ожило, но ненадолго. Чтобы понимать, выключаются “жирные” сервера всегда долго, поэтому до факта самого отключения может пройти и минут 6-7, а потом еще пару минут до запуска, то еще удовольствие. Решили отсоединить диск полностью и выключить логи, чтобы хоть что-то работало. Снова ребут – все работает. Ну, ок, больше не экспирементируем с разделением дисков, уговорили.
Что примечательно, когда я почти сразу расписал эту ситуацию саппорту, объяснив, что как-то не очень хорошо, когда мы теряем критические компоненты сервиса с неуловимыми косяками. Мне ответили на следующий день, часов через 16. Ответ классный:

We are sorry to hear you are seeing issues accessing that volume. In this case can you try detaching that volume, powering the droplet off, attaching it again then powering it back on. Please then run a file system check on that volume to be sure that there are not file system errors there causing issues.

Спасибо. Дальше я что-то писать не стал, понятно, что всем пофигу.
Второй раз повторилось примерно тоже самое. Давайте вспомним, что у нас уже один диск как и было раньше, все должно быть хорошо. Но через еще четыре дня снова прилег диск, но только теперь сразу был 99% iowait, а никакие ребуты не помогали. Получается, мы убили этот сервер) В этот раз мы просто переключились на реплику, она стала новым мастером. Старый Дроплет очнулся только через час! Удалили и забыли.
Выводы: что два диска, что один диск, обе этой херни сами понимаете что. Я писал в сапорт, чтобы они хоть как-то разобрались или сказали бы, что что-то пошло не так. Но мы до сих пор не знаем, ни что пошло не так, ни что толком делать, если повторится, кроме как менять дроплет.

3 случай

Это не то чтобы косяк и, наверное, надо было сразу читать документацию, но нормальные поцоны же не в курсе, что это. У DO есть так называемые Spaces – файловые хранилища по типу S3 бакетов Амазона. Собственно, это полный аналог с таким же апи, но одним небольшим отличием. У этих бакетов есть https://www.digitalocean.com/docs/spaces/ лимиты. Лимиты на операции записи, удаление и даже на объем загружаемого за день:

Spaces have the following request rate limits:
750 requests (any operation) per IP address per second to all Spaces on an account
150 PUTs, 150 DELETEs, 150 LISTs, and 240 other requests per second to any individual Space
2 COPYs per 5 minutes on any individual object in a Space

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

An error occurred (SlowDown) when calling the PutObject operation (reached max retries: 4): Please reduce your request rate.

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

4 случай

И снова проблема бакета. Я просто оставлю это здесь:

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

Что имеем

Имеем, что я однозначно буду советовать всем уезжать с DO, когда есть понимание, что проект сталкивается с большими нагрузками. Что будет происходить, если бы мы увеличились в наших RPS раза в три, я даже боюсь представить. Я уже молчу про аномальные сетевые ошибки, которые происходят периодами раз в пару дней, которые вообще никак толком не отловить.
DO идеален, чтобы поднять себе какой простенький впн (скачка торентиносов там, кстати, очень жестко палится, сразу приходят авто-страйки от правообладателей), хостить там свой сайт, на который никто кроме вашей мамы не заходит, или играться с новыми технологиями. У них много классных штук, тот же интерфейс дашбода вряд ли у кого-то найдется лучше, но внешний вид и исполнение все же принципиально разные вещи, а особенно в данном случае.
Я могу ошибаться, может это были частные случаи, но мой опыт таков. Пока писал этот текст, нашел, что существует Premier Support. Попробую узнать прайс и попробовать, может мой мир станет лучше.

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

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

Пример

Хотелось бы, чтобы такое вредительство было уголовно или хотя бы административно наказуемо, но предупрежден – значит вооружен. Идем по ссылке одинокого сервера на Ажуре. Создатель утверждает, что в этот бомбер добавлен 31 сервис. Вводим номер и ждем. Много смсок, наверное, не придет, но как пример для понимания процесса сойдет.
Такой сервер можно смело банить по адресу, но делу это особо не поможет. Человек, который это создал, наверняка поднял еще несколько таких же. Так же я предполагаю, что где-то в даркнете или еще на каких форумах мамкиных хакеров есть обновляемый список всех сервисов, которыми пользуются такие бомберы, с подробным описанием запросов в АПИ, куда надо ходить за СМСками.

Лол. Пока писал этот текст, нашел репу на Гитхабе с этим бомбером. Как я и утверждал выше, в ресурсах простейшие запросы на регу юзеров в KFC, Тинькофф и т.п. Reverse engineering enthusiast =)

Вывод

10 раз подумать, прежде чем начинать работать с SMS. Мало того, что это далеко не самый секьюрный способ авторизации, так еще и приобретаем такой вот геморрой. Мне понравилась система верификации юзеров в Badoo: они позволяют зарегаться без телефона, но при этом реализовали обучающуюся систему определения ботов и спамеров, которая в случае подозрений заставит уже зарегистрировавшегося и активного юзера подтвердить свою учетку по номеру. Я предполагаю, что запрос на код напрямую не отработает, если сервису это будет не нужно. В таком случае задача становится немного сложнее, чем прокинуть пару параметров по открытому методу. На их объемах это разумно, но небольшие сервисы этим заморачиваться не станут, а “реверс интузиазсты” будут и дальше этим пользоваться.
Для обычных юзеров, ставших жертвой бомбера, проблемы решаются через оператора. В видео в начале рассказано, что делать. Ну и, конечно же, не оставляйте свой номер, где попало.